Kial vi bezonas fari sekurkopiojn? Post ĉio, la ekipaĵo estas tre, tre fidinda, kaj krome, ekzistas "nuboj" pli bonaj en fidindeco ol fizikaj serviloj: kun taŭga agordo, "nuba" servilo povas facile postvivi la fiaskon de infrastruktura fizika servilo, kaj de la vidpunkto de servaj uzantoj, estos malgranda, apenaŭ rimarkebla salto en temposervo. Krome, multobligo de informoj ofte postulas pagi por "kroma" procesorotempo, diskoŝarĝo kaj rettrafiko.
Ideala programo funkcias rapide, ne likas memoron, ne havas truojn kaj ne ekzistas.
-Nekonata
Ĉar programoj ankoraŭ estas verkitaj de proteinprogramistoj, kaj ofte ne ekzistas testa procezo, krome programoj malofte estas liveritaj per "plej bonaj praktikoj" (kiuj mem ankaŭ estas programoj kaj tial neperfektaj), sistemadministrantoj plej ofte devas solvi problemojn, kiuj sonas mallonge sed koncize: “revenu kiel ĝi estis”, “portu la bazon al normala funkciado”, “funkcias malrapide - reiru”, kaj ankaŭ mia plej ŝatata “Mi ne scias kio, sed riparu ĝin”.
Krom logikaj eraroj, kiuj aperas kiel rezulto de senzorga laboro de programistoj, aŭ kombinaĵo de cirkonstancoj, same kiel nekompleta scio aŭ miskompreno de malgrandaj funkcioj de konstruprogramoj - inkluzive de konekto kaj sistemaj, inkluzive de operaciumoj, ŝoforoj kaj firmvaro - estas ankaŭ aliaj eraroj. Ekzemple, la plej multaj programistoj fidas je rultempo, tute forgesante pri fizikaj leĝoj, kiujn ankoraŭ neeblas eviti uzante programojn. Ĉi tio inkluzivas la senfinan fidindecon de la disksubsistemo kaj, ĝenerale, ajna datumstokado subsistemo (inkluzive RAM kaj procesoro kaŝmemoro!), kaj nula pretiga tempo sur la procesoro, kaj la foresto de eraroj dum transdono tra la reto kaj dum prilaborado sur la procesoro, kaj reto latenteco, kiu estas egala al 0. Vi ne devas neglekti la konatan limdaton, ĉar se vi ne renkontas ĝin ĝustatempe, estos problemoj pli malbonaj ol la nuancoj de reto kaj disko funkciado.
Kion fari kun problemoj, kiuj plene leviĝas kaj pendas super valoraj datumoj? Estas nenio por anstataŭigi vivantajn programistojn, kaj ne estas fakto, ke ĝi eblos baldaŭ. Aliflanke, nur kelkaj projektoj sukcesis plene pruvi, ke la programo funkcios kiel celite, kaj ne nepre eblos preni kaj apliki la pruvojn al aliaj, similaj projektoj. Ankaŭ tia evidenteco prenas multan tempon kaj postulas specialajn kapablojn kaj scion, kaj ĉi tio preskaŭ minimumigas la eblecon de ilia uzo konsiderante limdatojn. Krome, ni ankoraŭ ne scias kiel uzi ultrarapidan, malmultekostan kaj senfine fidindan teknologion por konservi, prilabori kaj transdoni informojn. Tiaj teknologioj, se ili ekzistas, estas en formo de konceptoj, aŭ – plej ofte – nur en sciencfikciaj libroj kaj filmoj.
Bonaj artistoj kopias, grandaj artistoj ŝtelas.
—Pablo Picasso.
La plej sukcesaj solvoj kaj surprize simplaj aferoj kutime okazas kie konceptoj, teknologioj, scio kaj sciencofakoj kiuj estas absolute malkongruaj unuavide renkontiĝas.
Ekzemple, birdoj kaj aviadiloj havas flugilojn, sed malgraŭ la funkcia simileco - la principo de funkciado en iuj reĝimoj estas la sama, kaj teknikaj problemoj estas solvitaj simile: kavaj ostoj, uzo de fortaj kaj malpezaj materialoj ktp. - la rezultoj estas tute malsamaj, kvankam tre similaj. La plej bonaj ekzemploj, kiujn ni vidas en nia teknologio, estas ankaŭ grandparte pruntitaj de la naturo: la premizitaj kupeoj de ŝipoj kaj submarŝipoj estas rekta analogio kun anelidoj; building raid arrays and checking data integrity - duobligi la DNA-ĉenon; same kiel parigitaj organoj, sendependeco de la laboro de malsamaj organoj de la centra nervosistemo (aŭtomatigo de la koro) kaj refleksoj - aŭtonomaj sistemoj en Interreto. Kompreneble, preni kaj apliki pretajn solvojn "fronte" estas plena de problemoj, sed kiu scias, eble ne ekzistas aliaj solvoj.
Se mi nur scius, kien vi falus, mi elmetus pajlojn!
—Belorusa popola proverbo
Ĉi tio signifas, ke rezervaj kopioj estas esencaj por tiuj, kiuj volas:
- Povu restarigi la funkciadon de viaj sistemoj kun minimuma malfunkcio, aŭ eĉ sen ĝi
- Agu kuraĝe, ĉar en kazo de eraro ĉiam ekzistas la ebleco de retroigo
- Minimumu la konsekvencojn de intencita datuma korupto
Jen malgranda teorio
Ajna klasifiko estas arbitra. Naturo ne klasifikas. Ni klasifikas ĉar ĝi estas pli oportuna por ni. Kaj ni klasifikas laŭ datumoj, kiujn ni ankaŭ prenas arbitre.
—Jean Bruler
Sendepende de la fizika stokado-metodo, logika datumstokado povas esti dividita en du manierojn por aliri ĉi tiujn datumojn: bloko kaj dosiero. Ĉi tiu divido estis lastatempe tre malklara, ĉar pure bloko, same kiel pure dosiero, logika stokado ne ekzistas. Tamen, por simpleco, ni supozos ke ili ekzistas.
Blokdatumstokado implicas ke ekzistas fizika aparato kie datumoj estas skribitaj en certaj fiksaj partoj, blokoj. Blokoj estas aliritaj ĉe certa adreso; ĉiu bloko havas sian propran adreson ene de la aparato.
Sekurkopio estas kutime farita kopiante blokojn de datumoj. Por certigi datumintegrecon, la registrado de novaj blokoj, same kiel ŝanĝoj al ekzistantaj, estas suspenditaj en la momento de kopiado. Se ni prenas analogion de la ordinara mondo, la plej proksima estas ŝranko kun identaj numeritaj ĉeloj.
Dosiera datumstokado bazita sur la logika aparato-principo estas proksima al bloka stokado kaj ofte estas organizita supre. Gravaj diferencoj estas la ĉeesto de stoka hierarkio kaj homlegeblaj nomoj. Abstraktaĵo estas asignita en la formo de dosiero - nomita datuma areo, same kiel dosierujo - speciala dosiero en kiu priskriboj kaj aliro al aliaj dosieroj estas konservitaj. Dosieroj povas esti liveritaj kun pliaj metadatenoj: krea tempo, alirflagoj, ktp. Sekurkopioj estas kutime faritaj tiel: ili serĉas ŝanĝitajn dosierojn, poste kopias ilin al alia dosierstokado kun la sama strukturo. Datenintegreco estas kutime efektivigita per la foresto de dosieroj al kiuj estas skribitaj. Dosieraj metadatenoj estas sekurkopiitaj en la sama maniero. La plej proksima analogio estas biblioteko, kiu havas sekciojn kun malsamaj libroj, kaj ankaŭ havas katalogon kun homlegeblaj nomoj de la libroj.
Lastatempe oni foje priskribas alian eblon, el kiu principe komenciĝis la konservado de dosieroj, kaj kiu havas la samajn arkaikajn trajtojn: konservado de objektoj.
Ĝi diferencas de dosierstokado pro tio, ke ĝi ne havas pli ol unu nestadon (plata skemo), kaj la dosiernomoj, kvankam homlegeblaj, ankoraŭ pli taŭgas por prilaborado de maŝinoj. Farante sekurkopiojn, objektostokado plejofte estas traktita simile al dosierstokado, sed foje ekzistas aliaj opcioj.
— Estas du specoj de sistemadministrantoj, tiuj kiuj ne faras sekurkopiojn, kaj tiuj kiuj JAM faras.
- Fakte, estas tri tipoj: estas ankaŭ tiuj, kiuj kontrolas, ke sekurkopioj povas esti restarigitaj.-Nekonata
Ankaŭ indas kompreni, ke la datumrezervprocezo mem estas efektivigita de programoj, do ĝi havas ĉiujn samajn malavantaĝojn kiel iu ajn alia programo. Por forigi (ne forigi!) dependecon de la homa faktoro, kaj ankaŭ trajtojn - kiuj individue ne havas fortan efikon, sed kune povas doni rimarkindan efikon - la t.n. regulo 3-2-1. Estas multaj ebloj pri kiel deĉifri ĝin, sed mi pli ŝatas la jenan interpreton: 3 aroj de la samaj datumoj devas esti konservitaj, 2 aroj devas esti konservitaj en malsamaj formatoj, kaj 1 aro devas esti konservita en geografie malproksima stokado.
La konserva formato devas esti komprenata jene:
- Se estas dependeco de la fizika konserva metodo, ni ŝanĝas la fizikan metodon.
- Se estas dependeco de la logika konserva metodo, ni ŝanĝas la logikan metodon.
Por atingi la maksimuman efikon de la regulo 3-2-1, oni rekomendas ŝanĝi la stokan formaton ambaŭmaniere.
El la vidpunkto de la preteco de sekurkopio por ĝia celita celo - restarigi funkciecon - oni distingas inter "varmaj" kaj "malvarmaj" sekurkopioj. Varmaj diferencas de malvarmaj en nur unu afero: ili estas tuj pretaj por uzo, dum malvarmaj postulas kelkajn pliajn paŝojn por reakiro: malĉifrado, eltiro el la arkivo ktp.
Ne konfuzu varmajn kaj malvarmajn kopiojn kun interretaj kaj eksterrete kopioj, kiuj implicas fizikan izoladon de datumoj kaj, fakte, estas alia signo de la klasifiko de rezervaj metodoj. Do eksterreta kopio - ne rekte konektita al la sistemo kie ĝi devas esti restaŭrita - povas esti aŭ varma aŭ malvarma (laŭ preteco por reakiro). Reta kopio povas esti havebla rekte kie ĝi devas esti restaŭrita, kaj plej ofte ĝi estas varma, sed estas ankaŭ malvarmaj.
Krome, ne forgesu, ke la procezo de kreado de kopioj mem kutime ne finiĝas kun la kreado de unu rezerva kopio, kaj povas esti sufiĉe granda nombro da kopioj. Tial, necesas distingi inter plenaj sekurkopioj, t.e. tiuj kiuj povas esti restarigitaj sendepende de aliaj sekurkopioj, same kiel diferencigaj (pliigaj, diferencigaj, malkreskaj, ktp.) kopioj - tiuj kiuj ne povas esti restaŭrigitaj sendepende kaj postulas la preparan restarigon de unu aŭ pluraj aliaj sekurkopioj.
Diferencaj pliigaj sekurkopioj estas provo ŝpari rezervan stokan spacon. Tiel, nur ŝanĝitaj datumoj de la antaŭa sekurkopio estas skribitaj al la rezerva kopio.
Diferencaj dekrementaj estas kreitaj por la sama celo, sed en iom alimaniere: plena rezerva kopio estas farita, sed nur la diferenco inter la freŝa kopio kaj la antaŭa estas fakte konservita.
Aparte, indas konsideri la procezon de sekurkopio super stokado, kiu subtenas la foreston de stokado de duplikatoj. Tiel, se vi skribas plenajn sekurkopiojn sur ĝi, nur la diferencoj inter la sekurkopioj efektive estos skribitaj, sed la procezo de restarigo de la sekurkopioj estos simila al restarigo de plena kopio kaj tute travidebla.
Quis custodiet ipsos custodes?
(Kiu gardos la gardistojn mem? - lat.)
Ĝi estas tre malagrabla kiam ne ekzistas rezervaj kopioj, sed estas multe pli malbona se sekurkopio ŝajnas esti farita, sed dum restarigo rezultas, ke ĝi ne povas esti restarigita ĉar:
- La integreco de la fontaj datumoj estis endanĝerigita.
- La rezerva stokado estas difektita.
- Restarigo funkcias tre malrapide; vi ne povas uzi datumojn parte reakiritajn.
Taŭge konstruita rezerva procezo devas konsideri tiajn komentojn, precipe la unuajn du.
La integreco de la fontaj datumoj povas esti garantiita laŭ pluraj manieroj. La plej ofte uzataj estas la jenaj: a) kreado de momentfotoj de la dosiersistemo ĉe la bloknivelo, b) "frostigo" la stato de la dosiersistemo, c) speciala bloka aparato kun versio-stokado, d) sinsekva registrado de dosieroj aŭ blokoj. Kontrolsumoj ankaŭ estas aplikataj por certigi ke datumoj estas kontrolitaj dum reakiro.
Stokadkorupto ankaŭ povas esti detektita uzante ĉeksumojn. Plia metodo estas la uzo de specialaj aparatoj aŭ dosiersistemoj en kiuj jam registritaj datumoj ne povas esti ŝanĝitaj, sed novaj povas esti aldonitaj.
Por akceli reakiron, reakiro de datumoj estas uzata kun multoblaj procezoj por reakiro - kondiĉe ke ne ekzistas botelkolo en formo de malrapida reto aŭ malrapida disksistemo. Por ĉirkaŭiri la situacion kun parte reakiritaj datumoj, vi povas rompi la rezervan procezon en relative malgrandajn subtaskojn, ĉiu el kiuj estas farata aparte. Tiel, fariĝas eble konstante restarigi agadon antaŭdirante la reakirotempon. Ĉi tiu problemo plej ofte kuŝas en la organiza ebeno (SLA), do ni ne detale pritraktos ĉi tion.
Fakulo pri spicoj ne estas tiu, kiu aldonas ilin al ĉiu plado, sed tiu, kiu neniam aldonas ion kroman al ĝi.
-EN. Sinjavskij
Praktikoj pri la programaro uzata de sistemadministrantoj povas varii, sed la ĝeneralaj principoj ankoraŭ estas, unumaniere aŭ alie, la samaj, precipe:
- Estas forte rekomendite uzi pretajn solvojn.
- Programoj devus funkcii antaŭvideble, t.e. Ne devus esti nedokumentitaj trajtoj aŭ proplempunktoj.
- Agordi ĉiun programon devus esti tiel simpla, ke vi ne devas legi la manlibron aŭ trompfolion ĉiufoje.
- Se eble, la solvo estu universala, ĉar serviloj povas multe varii en siaj aparataj trajtoj.
Estas la sekvaj oftaj programoj por preni sekurkopiojn de blokaj aparatoj:
- dd, konata al veteranoj de sistema administrado, ĉi tio ankaŭ inkluzivas similajn programojn (la saman dd_rescue, ekzemple).
- Utilaĵoj enkonstruitaj en iuj dosiersistemoj kiuj kreas rubejon de la dosiersistemo.
- Ĉiovoraj utilecoj; ekzemple partclone.
- Propraj, ofte proprietaj, decidoj; ekzemple, NortonGhost kaj poste.
Por dosiersistemoj, la rezerva problemo estas parte solvita per metodoj aplikeblaj por blokaj aparatoj, sed la problemo povas esti solvita pli efike uzante, ekzemple:
- Rsync, ĝeneraluzebla programo kaj protokolo por sinkronigi la staton de dosiersistemoj.
- Enkonstruitaj arkivaj iloj (ZFS).
- Triaj arkivaj iloj; la plej populara reprezentanto estas gudro. Estas aliaj, ekzemple, dar - anstataŭaĵo de gudro celita al modernaj sistemoj.
Aparte, indas mencii programajn ilojn por certigi datuman konsistencon dum kreado de rezervaj kopioj. La plej ofte uzataj opcioj estas:
- Munti la dosiersistemon en nurlegebla reĝimo (ReadOnly), aŭ frostigi la dosiersistemon (frostigi) - la metodo estas de limigita aplikebleco.
- Krei momentfotojn de la stato de dosiersistemoj aŭ blokaj aparatoj (LVM, ZFS).
- La uzo de triaj iloj por organizi impresojn, eĉ en kazoj kie la antaŭaj punktoj ne povas esti provizitaj ial (programoj kiel hotcopy).
- La kopio-sur-ŝanĝa tekniko (CopyOnWrite), tamen, ĝi plej ofte estas ligita al la dosiersistemo uzata (BTRFS, ZFS).
Do, por malgranda servilo vi devas provizi rezervan skemon kiu plenumas la sekvajn postulojn:
- Facila uzebla - ne necesas specialaj aldonaj paŝoj dum operacio, minimumaj paŝoj por krei kaj restarigi kopiojn.
- Universala - funkcias kaj sur grandaj kaj malgrandaj serviloj; ĉi tio gravas kiam kreskas la nombro da serviloj aŭ grimpas.
- Instalita de pakaĵmanaĝero, aŭ en unu aŭ du komandoj kiel "elŝuti kaj malpakigi".
- Stalo - norma aŭ long-establita stoka formato estas uzata.
- Rapide en laboro.
Kandidatoj de tiuj, kiuj pli-malpli plenumas la postulojn:
- rdiff-rezervo
- rsnapshot
- rukto
- duobligi
- duobligo
- lasu dup
- Doni
- zbackup
- trankvila
- borgbackup
Virtuala maŝino (bazita sur XenServer) kun la sekvaj karakterizaĵoj estos uzata kiel testbenko:
- 4 kernoj 2.5 GHz,
- 16 GB RAM,
- 50 GB hibrida stokado (stokadosistemo kun kaŝmemoro sur SSD 20% de la grandeco de virtuala disko) en la formo de aparta virtuala disko sen dispartigo,
- Interreta kanalo de 200 Mbps.
Preskaŭ la sama maŝino estos uzata kiel rezerva ricevila servilo, nur kun malmola disko de 500 GB.
Operaciumo - Centos 7 x64: norma subdisko, kroma sekcio estos uzata kiel datumfonto.
Kiel komencajn datumojn, ni prenu WordPress-ejon kun 40 GB da amaskomunikilaj dosieroj kaj mysql-datumbazo. Ĉar virtualaj serviloj multe varias en karakterizaĵoj, kaj ankaŭ por pli bona reproduktebleco, jen
servilaj testaj rezultoj uzante sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (uzante pakigitan LuaJIT 2.1.0-beta3)
Kuri la teston kun jenaj ebloj:
Nombro de fadenoj: 4
Iniciatigante hazardan nombrogeneratoron de nuna tempo
Limo de primoj: 20000
Komencante laborfadenojn...
Fadenoj komenciĝis!
Rapida CPU:
eventoj je sekundo: 836.69
Trairo:
evento/j (eps): 836.6908
tempo pasita: 30.0039s
totala nombro de eventoj: 25104
Latenteco (ms):
min: 2.38
mezumo: 4.78
Maksimumo: 22.39
95-a percentilo: 10.46
sumo: 119923.64
Fadenoj justeco:
eventoj (avg/stddev): 6276.0000/13.91
ekzekuttempo (avg/stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=tutmonda --memory-total-size=100G --memory-oper=legu memorfunkciadon
sysbench 1.1.0-18a9f86 (uzante pakigitan LuaJIT 2.1.0-beta3)
Kuri la teston kun jenaj ebloj:
Nombro de fadenoj: 4
Iniciatigante hazardan nombrogeneratoron de nuna tempo
Kurante memorrapidecteston kun la sekvaj opcioj:
blokgrandeco: 1KiB
tuta grandeco: 102400 MiB
operacio: legi
amplekso: tutmonda
Komencante laborfadenojn...
Fadenoj komenciĝis!
Totalaj operacioj: 50900446 (1696677.10 por sekundo)
49707.47 MiB transdonitaj (1656.91 MiB/sec)
Trairo:
evento/j (eps): 1696677.1017
tempo pasita: 30.0001s
totala nombro de eventoj: 50900446
Latenteco (ms):
min: 0.00
mezumo: 0.00
Maksimumo: 24.01
95-a percentilo: 0.00
sumo: 39106.74
Fadenoj justeco:
eventoj (avg/stddev): 12725111.5000/137775.15
ekzekuttempo (avg/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=tutmonda --memory-total-size=100G --memory-oper=skribi memorfunkciadon
sysbench 1.1.0-18a9f86 (uzante pakigitan LuaJIT 2.1.0-beta3)
Kuri la teston kun jenaj ebloj:
Nombro de fadenoj: 4
Iniciatigante hazardan nombrogeneratoron de nuna tempo
Kurante memorrapidecteston kun la sekvaj opcioj:
blokgrandeco: 1KiB
tuta grandeco: 102400 MiB
operacio: skribi
amplekso: tutmonda
Komencante laborfadenojn...
Fadenoj komenciĝis!
Totalaj operacioj: 35910413 (1197008.62 por sekundo)
35068.76 MiB transdonitaj (1168.95 MiB/sec)
Trairo:
evento/j (eps): 1197008.6179
tempo pasita: 30.0001s
totala nombro de eventoj: 35910413
Latenteco (ms):
min: 0.00
mezumo: 0.00
Maksimumo: 16.90
95-a percentilo: 0.00
sumo: 43604.83
Fadenoj justeco:
eventoj (avg/stddev): 8977603.2500/233905.84
ekzekuttempo (avg/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run
sysbench 1.1.0-18a9f86 (uzante pakigitan LuaJIT 2.1.0-beta3)
Kuri la teston kun jenaj ebloj:
Nombro de fadenoj: 4
Iniciatigante hazardan nombrogeneratoron de nuna tempo
Ekstra dosiero malfermaj flagoj: (neniu)
128 dosieroj, po 8 MiB
1GiB totala dosiergrandeco
Grando de bloko 4 KiB
Nombro da IO-petoj: 0
Legado/Skriba proporcio por kombinita hazarda IO-testo: 1.50
Perioda FSYNC ebligita, vokante fsync() po 100 petoj.
Voki fsync() ĉe la fino de testo, Ebligita.
Uzante sinkronan I/O-reĝimon
Farante hazardan r/w-teston
Komencante laborfadenojn...
Fadenoj komenciĝis!
Trairo:
legu: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
skribi: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latenteco (ms):
min: 0.00
mezumo: 0.27
Maksimumo: 18.01
95-a percentilo: 1.08
sumo: 238469.45
Ĉi tiu noto komencas grandan
serio de artikoloj pri sekurkopio
- Rezervo, parto 1: Kial sekurkopio necesas, superrigardo de metodoj, teknologioj
- Rezerva Parto 2: Reviziado kaj testado de rsync-bazitaj rezerva iloj
- Rezerva Parto 3: Reviziado kaj testado de dupleco, duplikomo, jam dup
- Rezerva Parto 4: Revizio kaj testado de zbackup, restic, borgbackup
- Rezerva Parto 5: Testado de bacula kaj veeam sekurkopio por Linukso
- Rezerva Parto 6: Komparante Rezervaj Iloj
- Rezerva Parto 7: Konkludoj
fonto: www.habr.com