Hvorfor må du ta sikkerhetskopier? Tross alt er utstyret veldig, veldig pålitelig, og dessuten er det "skyer" som er bedre i pålitelighet enn fysiske servere: med riktig konfigurasjon kan en "sky"-server enkelt overleve feilen på en fysisk infrastrukturserver, og fra tjenestebrukernes synspunkt vil det være et lite, knapt merkbart hopp i tidstjenesten. I tillegg krever duplisering av informasjon ofte å betale for "ekstra" prosessortid, diskbelastning og nettverkstrafikk.
Et ideelt program kjører raskt, lekker ikke minne, har ingen hull og eksisterer ikke.
-Ukjent
Siden programmer fortsatt er skrevet av proteinutviklere, og det ofte ikke er noen testprosess, pluss at programmer sjelden leveres ved å bruke "beste praksis" (som i seg selv også er programmer og derfor ufullkomne), må systemadministratorer som oftest løse problemer som høres kort ut, men kortfattet: "gå tilbake til hvordan det var", "bring basen til normal drift", "fungerer sakte - rull tilbake", og også min favoritt "jeg vet ikke hva, men fiks det".
I tillegg til logiske feil som oppstår som et resultat av uforsiktig arbeid fra utviklere, eller en kombinasjon av omstendigheter, samt ufullstendig kunnskap eller misforståelse av de små funksjonene i byggeprogrammer - inkludert tilkobling og system, inkludert operativsystemer, drivere og fastvare - Det er også andre feil. For eksempel er de fleste utviklere avhengige av kjøretid, og glemmer helt fysiske lover, som fortsatt er umulige å omgå ved bruk av programmer. Dette inkluderer den uendelige påliteligheten til diskundersystemet og generelt et hvilket som helst datalagringsundersystem (inkludert RAM og prosessorbuffer!), og null behandlingstid på prosessoren, og fravær av feil under overføring over nettverket og under behandling på prosessor, og nettverksforsinkelse, som er lik 0. Du bør ikke overse den beryktede fristen, for hvis du ikke oppfyller den i tide, vil det være problemer som er verre enn nyansene til nettverks- og diskdrift.
Hva skal man gjøre med problemer som stiger for fullt og henger over verdifulle data? Det er ingenting som skal erstatte levende utviklere, og det er ikke et faktum at det vil være mulig i nær fremtid. På den annen side er det kun noen få prosjekter som har lykkes med å bevise fullt ut at programmet vil fungere etter hensikten, og det vil ikke nødvendigvis være mulig å ta og anvende bevisene på andre, lignende prosjekter. Slike bevis tar også mye tid og krever spesielle ferdigheter og kunnskaper, og dette minimerer praktisk talt muligheten for bruk av dem under hensyntagen til tidsfrister. I tillegg vet vi ennå ikke hvordan vi skal bruke ultrarask, billig og uendelig pålitelig teknologi for lagring, prosessering og overføring av informasjon. Slike teknologier, hvis de eksisterer, er i form av konsepter, eller - oftest - bare i science fiction-bøker og filmer.
Gode artister kopierer, store artister stjeler.
-Pablo picasso.
De mest vellykkede løsningene og overraskende enkle tingene skjer vanligvis der konsepter, teknologier, kunnskap og vitenskapsfelt som er absolutt uforenlige ved første øyekast møtes.
For eksempel har fugler og fly vinger, men til tross for den funksjonelle likheten - operasjonsprinsippet i noen moduser er det samme, og tekniske problemer løses på lignende måte: hule bein, bruk av sterke og lette materialer, etc. - resultatene er helt forskjellige, selv om de er veldig like. De beste eksemplene vi ser i vår teknologi er også i stor grad lånt fra naturen: trykkrommene til skip og ubåter er en direkte analogi med annelids; bygge raid-arrayer og sjekke dataintegritet - duplisere DNA-kjeden; så vel som sammenkoblede organer, uavhengighet av arbeidet til forskjellige organer fra sentralnervesystemet (automatisering av hjertet) og reflekser - autonome systemer på Internett. Selvfølgelig er det å ta og bruke ferdige løsninger "head-on" full av problemer, men hvem vet, kanskje er det ingen andre løsninger.
Hadde jeg bare visst hvor du ville falle, så hadde jeg lagt ut sugerør!
— Hviterussisk folkeordtak
Dette betyr at sikkerhetskopier er avgjørende for de som ønsker å:
- Være i stand til å gjenopprette driften av systemene dine med minimal nedetid, eller til og med uten i det hele tatt
- Handle frimodig, for i tilfelle feil er det alltid mulighet for tilbakeføring
- Minimer konsekvensene av forsettlig datakorrupsjon
Her er en liten teori
Enhver klassifisering er vilkårlig. Naturen klassifiserer ikke. Vi klassifiserer fordi det er mer praktisk for oss. Og vi klassifiserer etter data som vi også tar vilkårlig.
– Jean Bruler
Uavhengig av fysisk lagringsmetode, kan logisk datalagring deles inn i to måter å få tilgang til disse dataene på: blokk og fil. Denne inndelingen har nylig blitt svært uskarp, fordi logisk lagring av rent blokk, så vel som rent fil, ikke eksisterer. For enkelhets skyld vil vi imidlertid anta at de eksisterer.
Blokkdatalagring innebærer at det er en fysisk enhet der data skrives i visse faste deler, blokker. Blokker åpnes på en bestemt adresse; hver blokk har sin egen adresse i enheten.
En sikkerhetskopi lages vanligvis ved å kopiere blokker med data. For å sikre dataintegritet, suspenderes registreringen av nye blokker, samt endringer av eksisterende, ved kopiering. Hvis vi tar en analogi fra den vanlige verden, er det nærmeste et skap med identiske nummererte celler.
Fildatalagring basert på det logiske enhetsprinsippet er nær blokklagring og er ofte organisert på toppen. Viktige forskjeller er tilstedeværelsen av et lagringshierarki og menneskelesbare navn. En abstraksjon tildeles i form av en fil - et navngitt dataområde, samt en katalog - en spesiell fil der beskrivelser og tilgang til andre filer er lagret. Filer kan leveres med ekstra metadata: opprettelsestid, tilgangsflagg, etc. Sikkerhetskopier gjøres vanligvis på denne måten: de ser etter endrede filer, og kopierer dem deretter til en annen fillagring med samme struktur. Dataintegritet implementeres vanligvis ved fravær av filer som skrives til. Filmetadata sikkerhetskopieres på samme måte. Den nærmeste analogien er et bibliotek, som har seksjoner med forskjellige bøker, og har også en katalog med menneskelesbare navn på bøkene.
Nylig er det noen ganger beskrevet et annet alternativ, hvorfra i prinsippet fildatalagring begynte, og som har de samme arkaiske egenskapene: lagring av objektdata.
Den skiller seg fra fillagring ved at den ikke har mer enn én nesting (flat skjema), og filnavnene, selv om de er lesbare for mennesker, er fortsatt mer egnet for behandling av maskiner. Når du utfører sikkerhetskopiering, blir objektlagring oftest behandlet på samme måte som fillagring, men noen ganger er det andre alternativer.
— Det er to typer systemadministratorer, de som ikke tar backup, og de som ALLEREDE gjør det.
– Egentlig er det tre typer: det er også de som sjekker at sikkerhetskopier kan gjenopprettes.-Ukjent
Det er også verdt å forstå at selve sikkerhetskopieringsprosessen utføres av programmer, så den har alle de samme ulempene som alle andre programmer. For å fjerne (ikke eliminere!) avhengighet av den menneskelige faktoren, samt egenskaper – som hver for seg ikke har sterk effekt, men sammen kan gi en merkbar effekt – den s.k. regel 3-2-1. Det er mange alternativer for hvordan man kan tyde det, men jeg liker følgende tolkning bedre: 3 sett med samme data må lagres, 2 sett må lagres i forskjellige formater, og 1 sett må lagres i et geografisk fjernlager.
Lagringsformatet skal forstås som følger:
- Hvis det er en avhengighet av den fysiske lagringsmetoden, endrer vi den fysiske metoden.
- Hvis det er en avhengighet av den logiske lagringsmetoden, endrer vi den logiske metoden.
For å oppnå maksimal effekt av 3-2-1-regelen, anbefales det å endre lagringsformatet på begge måter.
Fra synspunktet om beredskapen til en sikkerhetskopi for dets tiltenkte formål - gjenoppretting av funksjonalitet - skilles det mellom "varme" og "kalde" sikkerhetskopier. Varme skiller seg fra kalde på bare én ting: de er umiddelbart klare til bruk, mens kalde krever noen ekstra trinn for gjenoppretting: dekryptering, uttrekk fra arkivet, etc.
Ikke forveksle varme og kalde kopier med online og offline kopier, som innebærer fysisk isolering av data og faktisk er et annet tegn på klassifiseringen av sikkerhetskopieringsmetoder. Så en frakoblet kopi - som ikke er direkte koblet til systemet der den må gjenopprettes - kan være enten varm eller kald (i form av beredskap for gjenoppretting). En nettkopi kan være tilgjengelig direkte der den skal restaureres, og som oftest er det varmt, men det finnes også kalde.
I tillegg, ikke glem at prosessen med å lage sikkerhetskopier i seg selv vanligvis ikke slutter med opprettelsen av en sikkerhetskopi, og det kan være et ganske stort antall kopier. Derfor er det nødvendig å skille mellom full backup, dvs. de som kan gjenopprettes uavhengig av andre sikkerhetskopier, samt differensielle (inkrementelle, differensielle, dekrementelle, etc.) kopier - de som ikke kan gjenopprettes uavhengig og krever foreløpig gjenoppretting av en eller flere andre sikkerhetskopier.
Differensielle inkrementelle sikkerhetskopier er et forsøk på å spare lagringsplass for backup. Dermed skrives kun endrede data fra forrige sikkerhetskopi til sikkerhetskopien.
Differensielle dekrementelle er opprettet for samme formål, men på en litt annen måte: en fullstendig sikkerhetskopi lages, men bare forskjellen mellom den ferske kopien og den forrige lagres faktisk.
Separat er det verdt å vurdere prosessen med sikkerhetskopiering over lagring, som støtter fravær av lagring av duplikater. Dermed, hvis du skriver fullstendige sikkerhetskopier på toppen av det, vil bare forskjellene mellom sikkerhetskopiene faktisk bli skrevet, men prosessen med å gjenopprette sikkerhetskopiene vil være lik gjenoppretting fra en full kopi og helt gjennomsiktig.
Vil du ha ipsos depot?
(Hvem skal vokte vekterne selv? - lat.)
Det er veldig ubehagelig når det ikke er sikkerhetskopier, men det er mye verre hvis en sikkerhetskopi ser ut til å ha blitt laget, men ved gjenoppretting viser det seg at den ikke kan gjenopprettes fordi:
- Integriteten til kildedataene har blitt kompromittert.
- Sikkerhetskopieringslagringen er skadet.
- Gjenoppretting fungerer veldig sakte; du kan ikke bruke data som er delvis gjenopprettet.
En riktig konstruert sikkerhetskopieringsprosess må ta hensyn til slike kommentarer, spesielt de to første.
Kildedataenes integritet kan garanteres på flere måter. De mest brukte er følgende: a) lage øyeblikksbilder av filsystemet på blokknivå, b) "fryse" tilstanden til filsystemet, c) en spesiell blokkenhet med versjonslagring, d) sekvensiell opptak av filer eller blokker. Kontrollsummer brukes også for å sikre at data blir verifisert under gjenoppretting.
Lagringskorrupsjon kan også oppdages ved hjelp av kontrollsummer. En ekstra metode er bruk av spesialiserte enheter eller filsystemer der allerede registrerte data ikke kan endres, men nye kan legges til.
For å fremskynde gjenoppretting brukes datagjenoppretting med flere prosesser for gjenoppretting - forutsatt at det ikke er noen flaskehals i form av et tregt nettverk eller tregt disksystem. For å komme rundt situasjonen med delvis gjenopprettede data, kan du dele opp sikkerhetskopieringsprosessen i relativt små deloppgaver, som hver utføres separat. Dermed blir det mulig å gjenopprette ytelsen konsekvent mens du forutsier gjenopprettingstiden. Dette problemet ligger oftest i organisasjonsplanet (SLA), så vi vil ikke dvele ved dette i detalj.
En ekspert på krydder er ikke den som tilsetter dem til hver rett, men den som aldri tilfører noe ekstra.
-I. Sinyavsky
Praksis for programvaren som brukes av systemadministratorer kan variere, men de generelle prinsippene er fortsatt, på en eller annen måte, de samme, spesielt:
- Det anbefales sterkt å bruke ferdige løsninger.
- Programmer skal fungere forutsigbart, dvs. Det skal ikke være udokumenterte funksjoner eller flaskehalser.
- Å sette opp hvert program skal være så enkelt at du ikke trenger å lese manualen eller juksearket hver gang.
- Hvis mulig bør løsningen være universell, fordi servere kan variere sterkt i maskinvareegenskaper.
Det er følgende vanlige programmer for å ta sikkerhetskopier fra blokkerte enheter:
- dd, kjent for systemadministrasjonsveteraner, inkluderer dette også lignende programmer (samme dd_rescue, for eksempel).
- Verktøy innebygd i enkelte filsystemer som lager en dump av filsystemet.
- Altetende verktøy; for eksempel partclone.
- Egne, ofte proprietære, beslutninger; for eksempel NortonGhost og senere.
For filsystemer løses sikkerhetskopieringsproblemet delvis ved å bruke metoder som gjelder for blokkenheter, men problemet kan løses mer effektivt ved å for eksempel:
- Rsync, et generell program og protokoll for å synkronisere tilstanden til filsystemer.
- Innebygde arkiveringsverktøy (ZFS).
- Tredjeparts arkiveringsverktøy; den mest populære representanten er tjære. Det er andre, for eksempel dar - en erstatning for tjære rettet mot moderne systemer.
Det er verdt å nevne separat om programvareverktøy for å sikre datakonsistens når du lager sikkerhetskopier. De mest brukte alternativene er:
- Montering av filsystemet i skrivebeskyttet modus (ReadOnly), eller frysing av filsystemet (frys) - metoden har begrenset anvendelighet.
- Lage øyeblikksbilder av tilstanden til filsystemer eller blokkenheter (LVM, ZFS).
- Bruk av tredjepartsverktøy for å organisere visninger, selv i tilfeller der de tidligere punktene av en eller annen grunn ikke kan gis (programmer som hotcopy).
- Kopier-ved-endringsteknikken (CopyOnWrite), men den er oftest knyttet til filsystemet som brukes (BTRFS, ZFS).
Så for en liten server må du gi et sikkerhetskopieringsskjema som oppfyller følgende krav:
- Enkel å bruke - ingen spesielle tilleggstrinn kreves under drift, minimale trinn for å lage og gjenopprette kopier.
- Universal - fungerer på både store og små servere; dette er viktig når du skal øke antall servere eller skalere.
- Installert av en pakkebehandling, eller i en eller to kommandoer som "last ned og pakke ut".
- Stabilt - et standard eller lenge etablert lagringsformat brukes.
- Rask i jobb.
Søkere fra de som mer eller mindre oppfyller kravene:
- rdiff-sikkerhetskopi
- rsnapshot
- å rape
- duplikat
- dobbelthet
- la dup
- dar
- zbackup
- restisk
- borgbackup
En virtuell maskin (basert på XenServer) med følgende egenskaper vil bli brukt som en testbenk:
- 4 kjerner 2.5 GHz,
- 16 GB RAM,
- 50 GB hybrid lagring (lagringssystem med caching på SSD 20 % av den virtuelle diskstørrelsen) i form av en separat virtuell disk uten partisjonering,
- 200 Mbits Internett-kanal.
Nesten samme maskin vil bli brukt som backup-mottakerserver, bare med en 500 GB harddisk.
Operativsystem - Centos 7 x64: standard partisjon, ekstra partisjon vil bli brukt som datakilde.
Som innledende data, la oss ta et WordPress-nettsted med 40 GB med mediefiler og en mysql-database. Siden virtuelle servere varierer mye i egenskaper, og også for bedre reproduserbarhet, her er
servertestresultater ved hjelp av sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (bruker medfølgende LuaJIT 2.1.0-beta3)
Kjører testen med følgende alternativer:
Antall tråder: 4
Initialiserer tilfeldig tallgenerator fra gjeldende tid
Grense for primtall: 20000 XNUMX
Initialiserer arbeidertråder …
Trådene startet!
CPU-hastighet:
hendelser per sekund: 836.69
gjennomløp:
hendelser/er (eps): 836.6908
medgått tid: 30.0039s
totalt antall arrangementer: 25104
Latens (ms):
min: 2.38
gjennomsnitt: 4.78
maks: 22.39
95. persentil: 10.46
sum: 119923.64
Tråder rettferdighet:
hendelser (avg/stddev): 6276.0000/13.91
utførelsestid (avg/stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run
sysbench 1.1.0-18a9f86 (bruker medfølgende LuaJIT 2.1.0-beta3)
Kjører testen med følgende alternativer:
Antall tråder: 4
Initialiserer tilfeldig tallgenerator fra gjeldende tid
Kjører minnehastighetstest med følgende alternativer:
blokkstørrelse: 1KiB
total størrelse: 102400MiB
operasjon: les
omfang: globalt
Initialiserer arbeidertråder …
Trådene startet!
Totale operasjoner: 50900446 (1696677.10 per sekund)
49707.47 MiB overført (1656.91 MiB/sek)
gjennomløp:
hendelser/er (eps): 1696677.1017
medgått tid: 30.0001s
totalt antall arrangementer: 50900446
Latens (ms):
min: 0.00
gjennomsnitt: 0.00
maks: 24.01
95. persentil: 0.00
sum: 39106.74
Tråder rettferdighet:
hendelser (avg/stddev): 12725111.5000/137775.15
utførelsestid (avg/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=skriveminnekjøring
sysbench 1.1.0-18a9f86 (bruker medfølgende LuaJIT 2.1.0-beta3)
Kjører testen med følgende alternativer:
Antall tråder: 4
Initialiserer tilfeldig tallgenerator fra gjeldende tid
Kjører minnehastighetstest med følgende alternativer:
blokkstørrelse: 1KiB
total størrelse: 102400MiB
operasjon: skriv
omfang: globalt
Initialiserer arbeidertråder …
Trådene startet!
Totale operasjoner: 35910413 (1197008.62 per sekund)
35068.76 MiB overført (1168.95 MiB/sek)
gjennomløp:
hendelser/er (eps): 1197008.6179
medgått tid: 30.0001s
totalt antall arrangementer: 35910413
Latens (ms):
min: 0.00
gjennomsnitt: 0.00
maks: 16.90
95. persentil: 0.00
sum: 43604.83
Tråder rettferdighet:
hendelser (avg/stddev): 8977603.2500/233905.84
utførelsestid (avg/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-modus=rndrw --time=60 --file-block-size=4K --file-total-size=1G filiokjøring
sysbench 1.1.0-18a9f86 (bruker medfølgende LuaJIT 2.1.0-beta3)
Kjører testen med følgende alternativer:
Antall tråder: 4
Initialiserer tilfeldig tallgenerator fra gjeldende tid
Ekstra fil åpne flagg: (ingen)
128 filer, 8MB hver
1GiB total filstørrelse
Blokkstørrelse 4KiB
Antall IO-forespørsler: 0
Lese/skrive-forhold for kombinert tilfeldig IO-test: 1.50
Periodisk FSYNC aktivert, kaller fsync() hver 100 forespørsler.
Kaller fsync() på slutten av testen, aktivert.
Bruker synkron I/O-modus
Gjør tilfeldig r/w test
Initialiserer arbeidertråder …
Trådene startet!
gjennomløp:
les: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
skriv: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latens (ms):
min: 0.00
gjennomsnitt: 0.27
maks: 18.01
95. persentil: 1.08
sum: 238469.45
Dette notatet begynner stort
serie artikler om sikkerhetskopiering
- Sikkerhetskopiering, del 1: Hvorfor sikkerhetskopiering er nødvendig, en oversikt over metoder, teknologier
- Sikkerhetskopiering del 2: Gjennomgang og testing av rsync-baserte sikkerhetskopieringsverktøy
- Backup Del 3: Gjennomgang og testing av duplisitet, duplikat, deja dup
- Backup Del 4: Gjennomgang og testing av zbackup, restic, borgbackup
- Sikkerhetskopiering del 5: Tester bacula og veeam backup for linux
- Sikkerhetskopiering del 6: Sammenligning av sikkerhetskopieringsverktøy
- Backup Del 7: Konklusjoner
Kilde: www.habr.com