Zagotovitev varnostnih kopij ni nekaj, kar bi se obravnavalo kot moderna tehnologija, ki jo oglašujejo na vsakem koraku. Preprosto mora biti v vsakem resnem podjetju, to je vse. V naši banki se varnostne kopije opravljajo za več tisoč strežnikov – to je zapleteno, zanimivo delo, o nekaterih finih podrobnostih, pa tudi o tipičnih zmotah glede varnostnih kopij, bi rad spregovoril.
S to tematiko se ukvarjam že skoraj 20 let, od tega zadnji 2 leti v Promsvyazbank. Na začetku prakse sem skoraj ročno izvajal varnostne kopije, s skripti, ki so preprosto kopirali datoteke. Nato so v Windows prišli uporabniški pripomočki: orodje Robocopy za pripravo datotek in NT Backup za kopiranje. Kasneje je prišel čas za specializirano programsko opremo, predvsem Veritas Backup Exec, ki se sedaj imenuje Symantec Backup Exec. Tako da sem z varnostnimi kopijami že dolgo na tekočem.
Če rečemo po domače, varnostno kopiranje je shranjevanje kopije podatkov (virtualnih naprav, aplikacij, podatkovnih baz in datotek) za vsak primer z določeno rednostjo. Vsak primer običajno nastane v obliki tamponske ali logične napake, kar lahko privede do izgube podatkov. Naloga sistema varnostnega kopiranja je zmanjšati izgube zaradi izgube informacij. Napaka strojne opreme je na primer okvara strežnika ali shranjevanja, kjer je baza podatkov. Logična napaka pa je izguba ali sprememba dela podatkov, vključno z napakami zaradi človeškega dejavnika: nenamerno brisanje tabele, datoteke, zagon napačnega skripta. Obstoječe so tudi zahteve regulatorjev glede shranjevanja določenega tipa informacij v daljšem obdobju, na primer do več let.
Najpogostejša uporaba varnostnih kopij pa je obnova shranjene kopije podatkovnih baz za uvajanje različnih testnih sistemov, klonov za razvijalce.
Okoli varnostnega kopiranja kroži več tipičnih mitov, ki jih je že skrajni čas razbliniti. Tukaj so najpoznaneši med njimi.
Mit 1. Varnostna kopija je že dolgo le majhna funkcija znotraj sistemov varnosti ali shranjevanja.
Sistemi za pravljenje rezervnih kopija i dalje ostaju poseban razred rešenja, i izuzetno su nezavisni. Previše je važno poveriti im tako suštinskog posla. U suštini, oni su poslednja linija odbrane kada je reč o očuvanju podataka. Dakle, pravljenje rezervnih kopija funkcioniše u svom ritmu, prema svom vlastitom rasporedu. Svakodnevni izveštaj se priprema za servere, a događaji deluju kao okidači za sistem praćenja.
Pored toga, model pristupa sistemu rezervnih kopija omogućava delegiranje dela ovlašćenja administrativnim osobama ciljanih sistema za upravljanje rezervnim kopijama.
Mit 2. Kada postoji RAID, rezervne kopije više nisu potrebne
Nesumnjivo, RAID nizovi i replikacija podataka su dobar način zaštite informacionih sistema od hardverskih kvarova, a u prisustvu standby servera — brzog prelaska na njega u slučaju kvara glavne mašine.
Prema logičkim greškama koje su napravili korisnici sistema, redundantnost i replikacija ne pomažu. Da, standby server sa odloženim zapisom može pomoći, ako je greška otkrivena pre nego što je sinhronizovana. A ako je trenutak propušten? Tada pomaže samo pravovremena rezervna kopija. Ako je poznato da su se podaci izmenili juče, moguće je vratiti sistem na stanje od prejučer i izvući potrebne podatke. Imajući u vidu da su logičke greške najčešće, stara dobra rezervna kopija ostaje provereno i potrebno sredstvo.
Mit 3. Rezervne kopije se prave jednom mesečno.
Frekvencija pravljenja rezervnih kopija je podesiv parametar, koji prvenstveno zavisi od zahteva za sistemom rezervnih kopija. Sasvim je realno pronaći podatke koji se praktično nikada ne menjaju i nisu posebno važni, njihovo gubljenje neće biti kritično za kompaniju.
Njih, zaista, možete praviti rezervne kopije jednom mesečno ili čak ređe. Međutim, kritičniji podaci se čuvaju češće, u zavisnosti od RPO (Recovery Point Objective) pokazatelja, koji definiše dozvoljeni gubitak podataka. To može biti jednom nedeljno, jednom dnevno ili čak više puta na sat. Kod nas su to logovi transakcija iz baze podataka.
При внедрении систем в промышленную эксплуатацию необходимо утвердить документацию по резервному копированию, в которой изложены основные положения, график обновлений, порядок восстановления системы, правила хранения резервных копий и тому подобное.
Миф 4. Объем копий непрерывно растет и полностью заполняет любое выделенное пространство.
Резервные копии имеют ограниченный срок хранения. Нет смысла накапливать все 365 ежедневных резервных копий в течение года. Обычно разрешается хранить ежедневные копии в течение 2 недель, после чего они заменяются новыми, а на длительное хранение остается версия, которая была сделана первой в месяце. Эта версия также хранится определенное время – у каждой копии есть срок хранения.
Существует защита от потери данных. Действует правило: прежде чем бэкап будет удален, должен быть создан следующий. Таким образом, данные не будут удалены, если резервное копирование не удалось, например, из-за недоступности сервера. Соблюдаются не только временные рамки, но и контролируется количество копий в наборе. Если в системе предусмотрено, что должно быть два полных бэкапа, их всегда будет два, и старая копия будет удалена только тогда, когда будет успешно записан новый третий. Таким образом, увеличение объема, занимаемого архивом резервных копий, связано только с ростом количества защищаемых данных и не зависит от времени.
Миф 5. Начался бэкап – всё зависло.
Правильнее было бы сказать так: если всё зависло, значит, дело не в системе, а в квалификации администратора. В действительности, быстродействие резервного копирования зависит от множества факторов, например, от производительности самой системы резервного копирования: насколько быстро работают дисковые хранилища и ленточные библиотеки. strežnikov От быстродействия системы резервного копирования: успевают ли они обрабатывать данные, осуществлять сжатие и дедупликацию. Также это зависит от скорости передачи данных между клиентом и сервером.
Резервное копирование может выполняться в одном или нескольких потоках, в зависимости от того, поддерживает ли резервируемая система многопоточность. Например, СУБД Oracle позволяет использовать несколько потоков, соответствующих количеству доступных процессоров, пока скорость передачи не достигнет предела пропускной способности сети.
Če poskušate varnostno kopirati z veliko povezavami, obstaja možnost, da preobremenite delovni sistem, kar lahko privede do zastojev. Zato je izbrano optimalno število povezav, da se zagotovi zadostna hitrost delovanja. Če pa je tudi najmanjši upad hitrost kritičen, obstaja odlična možnost, da se varnostno kopiranje opravi ne s produkcijskega strežnika, temveč z njegovim klonom – standby v terminologiji baz podatkov. Ta postopek ne obremenjuje glavnega delovnega sistema. Podatke je mogoče pridobiti preko več povezav, saj strežnik ni obremenjen z obdelavo.
V velikih organizacijah se za sistem varnostnega kopiranja ustvari ločena mreža, da varnostno kopiranje ne vpliva na produkcijo. Poleg tega se lahko promet prenaša ne preko mreže, temveč preko SAN.
Trudimo se razporediti obremenitev tudi po času. Varnostne kopije se večinoma izvajajo v neobdelovnem času: ponoči, ob koncih tedna. Poleg tega se ne zaženejo vse hkrati. Varnostne kopije virtualnih strojev so poseben primer. Postopek praktično ne vpliva na zmogljivost samega stroja, zato lahko varnostno kopiranje razdelimo čez dan, namesto da bi vse prestavili na noč. Občutkov je veliko, če vse upoštevamo, varnostno kopiranje ne vpliva na zmogljivost sistemov.
Mit 6. Zagnal sem sistem varnostnega kopiranja – in dobil odpornosti.
Nikoli ne pozabite, da je sistem za varnostno kopiranje zadnja obrambna linija, kar pomeni, da mora pred njim biti še nekaj sistemov, ki zagotavljajo kontinuiteto, visoko dostopnost in odpornost IT-infrastrukture ter informacijskih sistemov podjetja.
Ne smete upati, da bo varnostno kopiranje obnovilo vse podatke in hitro oživilo padec storitve. Izguba podatkov od trenutka varnostnega kopiranja do trenutka okvare je zagotovljena, podatki na novem strežniku pa se lahko nalagajo več ur (ali dni, odvisno od sreče). Zato je smiselno ustvariti popolne odpornosti, ne da bi vse prenesli na varnostno kopiranje.
Mit 7. Enkrat sem nastavljen varnostno kopiranje, preveril, da deluje. Preostane le gledanje dnevnikov.
To je en mit, ki je eden najbolj škodljivih, čigar napačnost spoznamo šele ob incidentu. Dnevniki o uspešni varnostni kopiji niso zagotovilo, da je vse potekalo, kot bi moralo. Shranjeno kopijo je pomembno vnaprej preveriti za razpoložljivost. To pomeni, da je treba zagnati proces obnovitve v testnem okolju in preveriti rezultat.
In malo o delu sistemskega administratorja
V ročnem načinu nihče več ne kopira podatkov. Sodobni SRK-ji znajo varnostno kopirati skoraj vse, le da ga je treba ustrezno nastaviti. Če dodamo nov strežnik – je treba določiti politike: izbrati vsebino, ki jo bomo varnostno kopirali, določiti shranjevalne parametre in uporabiti razpored.
Kljub temu je dela kar precej zaradi obsežnega parka strežnikov, med katerimi so tako podatkovne baze, kot poštni sistemi, klasterji virtualnih strojev in datotečni viri tako na Windows kot na Linux/Unix. Zaposleni, ki vzdržujejo delovanje sistema za varnostno kopiranje, ne sedijo brez dela.
Ob prazniku želim vsem administratorjem močne živce, natančnost gibov in neskončen prostor za shranjevanje varnostnih kopij!
Izvor: habr.com
