Hvorfor skal du lave sikkerhedskopier? Udstyret er jo meget, meget pålideligt, og derudover er der "skyer", der er bedre i pålidelighed end fysiske servere: med korrekt konfiguration kan en "sky"-server nemt overleve fejlen på en fysisk infrastrukturserver, og fra tjenestebrugernes synspunkt, vil der være et lille, knapt mærkbart spring i tidstjenesten. Derudover kræver duplikering af information ofte betaling for "ekstra" processortid, diskbelastning og netværkstrafik.
Et ideelt program kører hurtigt, lækker ikke hukommelse, har ingen huller og eksisterer ikke.
-Ukendt
Da programmer stadig er skrevet af proteinudviklere, og der ofte ikke er nogen testproces, plus at programmer sjældent leveres ved hjælp af "best practices" (som i sig selv også er programmer og derfor uperfekte), skal systemadministratorer oftest løse problemer, der lyder kort, men kortfattet: “vend tilbage til hvordan det var”, “bring basen til normal drift”, “arbejder langsomt – rul tilbage”, og også min favorit “jeg ved ikke hvad, men fix det”.
Ud over logiske fejl, der opstår som følge af skødesløst arbejde fra udviklere, eller en kombination af omstændigheder, samt ufuldstændig viden eller misforståelse af små funktioner i byggeprogrammer - herunder tilslutning og system, herunder operativsystemer, drivere og firmware - der er også andre fejl. For eksempel er de fleste udviklere afhængige af runtime og glemmer fuldstændigt de fysiske love, som stadig er umulige at omgå ved hjælp af programmer. Dette inkluderer den uendelige pålidelighed af diskundersystemet og generelt ethvert datalagerundersystem (inklusive RAM og processorcache!), og nul behandlingstid på processoren og fraværet af fejl under transmission over netværket og under behandling på processoren. processor og netværksforsinkelse, som er lig med 0. Du bør ikke forsømme den berygtede deadline, for hvis du ikke overholder den i tide, vil der være problemer, der er værre end nuancerne af netværks- og diskdrift.
Hvad skal man gøre med problemer, der stiger i fuld kraft og hænger over værdifulde data? Der er intet til at erstatte levende udviklere, og det er ikke et faktum, at det vil være muligt i den nærmeste fremtid. Til gengæld er det kun lykkedes få projekter fuldt ud at bevise, at programmet fungerer efter hensigten, og det vil ikke nødvendigvis være muligt at tage og anvende beviserne på andre lignende projekter. Sådanne beviser tager også meget tid og kræver særlige færdigheder og viden, og dette minimerer praktisk talt muligheden for deres brug under hensyntagen til deadlines. Derudover ved vi endnu ikke, hvordan vi bruger ultrahurtig, billig og uendelig pålidelig teknologi til lagring, behandling og transmission af information. Sådanne teknologier, hvis de findes, er i form af koncepter, eller - oftest - kun i science fiction-bøger og -film.
Gode kunstnere kopierer, store kunstnere stjæler.
- Pablo Picasso.
De mest succesrige løsninger og overraskende simple ting sker som regel, hvor koncepter, teknologier, viden og videnskabsområder, der er absolut uforenelige ved første øjekast, mødes.
For eksempel har fugle og fly vinger, men på trods af den funktionelle lighed - funktionsprincippet i nogle tilstande er det samme, og tekniske problemer løses på lignende måde: hule knogler, brug af stærke og lette materialer osv. - resultaterne er helt forskellige, men meget ens. De bedste eksempler, vi ser i vores teknologi, er også i høj grad lånt fra naturen: de tryksatte rum i skibe og ubåde er en direkte analogi med annelids; opbygning af raid-arrays og kontrol af dataintegritet - duplikere DNA-kæden; såvel som parrede organer, uafhængighed af arbejdet i forskellige organer fra centralnervesystemet (automatisering af hjertet) og reflekser - autonome systemer på internettet. Selvfølgelig er det at tage og anvende færdige løsninger "head-on" fyldt med problemer, men hvem ved, måske er der ingen andre løsninger.
Havde jeg bare vidst, hvor du ville falde, havde jeg lagt sugerør ud!
— Hviderussisk folkeordsprog
Det betyder, at sikkerhedskopier er afgørende for dem, der ønsker at:
- Være i stand til at genoprette driften af dine systemer med minimal nedetid, eller endda uden det overhovedet
- Handl modigt, for i tilfælde af en fejl er der altid mulighed for en tilbagerulning
- Minimer konsekvenserne af forsætlig datakorruption
Her er en lille teori
Enhver klassificering er vilkårlig. Naturen klassificerer ikke. Vi klassificerer, fordi det er mere bekvemt for os. Og vi klassificerer efter data, som vi også tager vilkårligt.
– Jean Bruler
Uanset den fysiske lagringsmetode kan logisk datalagring opdeles i to måder at få adgang til disse data på: blok og fil. Denne opdeling er for nylig blevet meget sløret, fordi rent blok, såvel som rent fil, logisk lagring eksisterer ikke. For nemheds skyld vil vi dog antage, at de eksisterer.
Blokdatalagring indebærer, at der er en fysisk enhed, hvor data skrives i bestemte faste dele, blokke. Blokke tilgås på en bestemt adresse; hver blok har sin egen adresse i enheden.
En sikkerhedskopi laves normalt ved at kopiere datablokke. For at sikre dataintegritet suspenderes optagelsen af nye blokke såvel som ændringer af eksisterende på kopieringstidspunktet. Hvis vi tager en analogi fra den almindelige verden, er det tætteste et skab med identiske nummererede celler.
Fildatalagring baseret på det logiske enhedsprincip er tæt på bloklagring og er ofte organiseret ovenpå. Vigtige forskelle er tilstedeværelsen af et lagerhierarki og menneskelæselige navne. En abstraktion tildeles i form af en fil - et navngivet dataområde samt en mappe - en speciel fil, hvori beskrivelser og adgang til andre filer er gemt. Filer kan forsynes med yderligere metadata: oprettelsestid, adgangsflag osv. Sikkerhedskopier udføres normalt på denne måde: de leder efter ændrede filer og kopierer dem derefter til et andet fillager med samme struktur. Dataintegritet implementeres normalt ved fravær af filer, der skrives til. Filmetadata sikkerhedskopieres på samme måde. Den nærmeste analogi er et bibliotek, som har sektioner med forskellige bøger, og som også har et katalog med menneskelæselige navne på bøgerne.
For nylig er der nogle gange beskrevet en anden mulighed, hvorfra i princippet fildatalagring begyndte, og som har de samme arkaiske træk: objektdatalagring.
Det adskiller sig fra fillagring ved, at det ikke har mere end én indlejring (fladt skema), og filnavnene, selvom de kan læses af mennesker, er stadig mere egnede til behandling af maskiner. Ved sikkerhedskopiering behandles objektlagring oftest på samme måde som fillagring, men nogle gange er der andre muligheder.
— Der er to typer systemadministratorer, dem der ikke laver backup, og dem der ALLEREDE gør.
- Faktisk er der tre typer: Der er også dem, der kontrollerer, at sikkerhedskopier kan gendannes.-Ukendt
Det er også værd at forstå, at selve datasikkerhedsprocessen udføres af programmer, så det har alle de samme ulemper som ethvert andet program. For at fjerne (ikke eliminere!) afhængighed af den menneskelige faktor, samt træk - som hver for sig ikke har en stærk effekt, men tilsammen kan give en mærkbar effekt - den såkaldte regel 3-2-1. Der er mange muligheder for hvordan man kan tyde det, men jeg kan bedre lide følgende fortolkning: 3 sæt af samme data skal gemmes, 2 sæt skal gemmes i forskellige formater, og 1 sæt skal gemmes i et geografisk fjernlager.
Opbevaringsformatet skal forstås som følger:
- Hvis der er afhængighed af den fysiske opbevaringsmetode, ændrer vi den fysiske metode.
- Hvis der er en afhængighed af den logiske lagringsmetode, ændrer vi den logiske metode.
For at opnå den maksimale effekt af 3-2-1-reglen anbefales det at ændre lagringsformatet på begge måder.
Ud fra synspunktet om klarheden af en sikkerhedskopi til dets tilsigtede formål - gendannelse af funktionalitet - skelnes der mellem "varme" og "kolde" sikkerhedskopier. Varme adskiller sig fra kolde på kun én ting: de er straks klar til brug, mens kolde kræver nogle ekstra trin til gendannelse: dekryptering, udtræk fra arkivet osv.
Forveksle ikke varme og kolde kopier med online og offline kopier, som indebærer fysisk isolering af data og faktisk er endnu et tegn på klassificeringen af backupmetoder. Så en offline kopi - ikke direkte forbundet til systemet, hvor den skal gendannes - kan enten være varm eller kold (i form af klarhed til genopretning). Et online eksemplar kan være tilgængeligt direkte, hvor det skal restaureres, og oftest er det varmt, men der er også kolde.
Derudover skal du ikke glemme, at selve processen med at oprette sikkerhedskopier normalt ikke ender med oprettelsen af en sikkerhedskopi, og der kan være et ret stort antal kopier. Derfor er det nødvendigt at skelne mellem fuld backup, dvs. dem, der kan gendannes uafhængigt af andre sikkerhedskopier, samt differentielle (inkrementelle, differentielle, dekrementelle, osv.) kopier - dem, der ikke kan gendannes uafhængigt og kræver foreløbig gendannelse af en eller flere andre sikkerhedskopier.
Differentielle inkrementelle sikkerhedskopier er et forsøg på at spare backuplagerplads. Det er således kun ændrede data fra den tidligere backup, der skrives til sikkerhedskopien.
Differentielle dekrementelle oprettes til samme formål, men på en lidt anden måde: Der laves en fuld sikkerhedskopi, men kun forskellen mellem den friske kopi og den forrige gemmes faktisk.
Separat er det værd at overveje processen med backup over lagring, som understøtter fraværet af lagring af dubletter. Hvis du således skriver fulde sikkerhedskopier oven på det, vil kun forskellene mellem sikkerhedskopierne faktisk blive skrevet, men processen med at gendanne sikkerhedskopierne vil ligne gendannelse fra en fuld kopi og fuldstændig gennemsigtig.
Quis custodiet ipsos custodes?
(Hvem skal vogte vægterne selv? - lat.)
Det er meget ubehageligt, når der ikke er nogen sikkerhedskopier, men det er meget værre, hvis der ser ud til at være lavet en sikkerhedskopi, men ved gendannelse viser det sig, at den ikke kan gendannes, fordi:
- Kildedataenes integritet er blevet kompromitteret.
- Sikkerhedskopieringslageret er beskadiget.
- Gendannelse fungerer meget langsomt; du kan ikke bruge data, der er delvist gendannet.
En korrekt konstrueret backupproces skal tage højde for sådanne kommentarer, især de to første.
Kildedataens integritet kan garanteres på flere måder. De mest brugte er følgende: a) oprettelse af snapshots af filsystemet på blokniveau, b) "frysning" af filsystemets tilstand, c) en speciel blokenhed med versionslagring, d) sekventiel optagelse af filer eller blokke. Kontrolsummer anvendes også for at sikre, at data verificeres under gendannelse.
Lagerkorruption kan også opdages ved hjælp af kontrolsummer. En yderligere metode er brugen af specialiserede enheder eller filsystemer, hvor allerede registrerede data ikke kan ændres, men nye kan tilføjes.
For at fremskynde gendannelsen bruges datagendannelse med flere processer til gendannelse - forudsat at der ikke er nogen flaskehals i form af et langsomt netværk eller langsomt disksystem. For at komme uden om situationen med delvist gendannede data, kan du opdele backup-processen i relativt små underopgaver, som hver især udføres separat. Det bliver således muligt konsekvent at genoprette ydeevnen, mens man forudsiger genoprettelsestiden. Dette problem ligger oftest i det organisatoriske plan (SLA), så vi vil ikke dvæle ved dette i detaljer.
En ekspert i krydderier er ikke den, der tilføjer dem til hver ret, men den, der aldrig tilføjer noget ekstra til det.
-I. Sinyavsky
Praksis vedrørende softwaren, der bruges af systemadministratorer, kan variere, men de generelle principper er stadig på den ene eller anden måde de samme, især:
- Det anbefales kraftigt at bruge færdige løsninger.
- Programmer skal fungere forudsigeligt, dvs. Der bør ikke være udokumenterede funktioner eller flaskehalse.
- Opsætning af hvert program skal være så enkelt, at du ikke behøver at læse manualen eller snydeark hver gang.
- Hvis det er muligt, bør løsningen være universel, fordi servere kan variere meget i deres hardwareegenskaber.
Der er følgende almindelige programmer til at tage sikkerhedskopier fra blokenheder:
- dd, som er kendt for veteraner fra systemadministration, inkluderer også lignende programmer (f.eks. den samme dd_rescue).
- Hjælpeprogrammer indbygget i nogle filsystemer, der skaber et dump af filsystemet.
- Altædende hjælpemidler; for eksempel partclone.
- Egne, ofte proprietære, beslutninger; for eksempel NortonGhost og senere.
For filsystemer løses sikkerhedskopieringsproblemet delvist ved hjælp af metoder, der gælder for blokenheder, men problemet kan løses mere effektivt ved at f.eks.
- Rsync, et generelt program og protokol til synkronisering af filsystemernes tilstand.
- Indbyggede arkiveringsværktøjer (ZFS).
- Tredjeparts arkiveringsværktøjer; den mest populære repræsentant er tjære. Der er andre, for eksempel dar - en erstatning for tjære rettet mod moderne systemer.
Det er værd at nævne separat om softwareværktøjer til at sikre datakonsistens ved oprettelse af sikkerhedskopier. De mest brugte muligheder er:
- Montering af filsystemet i skrivebeskyttet tilstand (ReadOnly), eller frysning af filsystemet (frys) - metoden er af begrænset anvendelighed.
- Oprettelse af snapshots af tilstanden af filsystemer eller blokenheder (LVM, ZFS).
- Brugen af tredjepartsværktøjer til at organisere indtryk, selv i tilfælde, hvor de foregående punkter af en eller anden grund ikke kan gives (programmer som hotcopy).
- Kopier-på-skift-teknikken (CopyOnWrite), er dog oftest bundet til det anvendte filsystem (BTRFS, ZFS).
Så for en lille server skal du levere et backupskema, der opfylder følgende krav:
- Nem at bruge - der kræves ingen særlige yderligere trin under drift, minimale trin til at oprette og gendanne kopier.
- Universal - fungerer på både store og små servere; dette er vigtigt, når du øger antallet af servere eller skalerer.
- Installeret af en pakkeadministrator eller i en eller to kommandoer som "download og udpak".
- Stabil - der bruges et standard eller længe etableret lagerformat.
- Hurtig i arbejde.
Ansøgere fra dem, der mere eller mindre opfylder kravene:
- rdiff-backup
- rsnapshot
- bøvs
- duplikere
- dobbelthed
- lad dup
- dar
- zbackup
- restisk
- borgbackup
En virtuel maskine (baseret på XenServer) med følgende egenskaber vil blive brugt som en testbænk:
- 4 kerner 2.5 GHz,
- 16 GB RAM,
- 50 GB hybridlager (lagersystem med caching på SSD 20% af den virtuelle diskstørrelse) i form af en separat virtuel disk uden partitionering,
- 200 Mbps internetkanal.
Næsten den samme maskine vil blive brugt som backup-modtagerserver, kun med en 500 GB harddisk.
Operativsystem - Centos 7 x64: standardpartition, yderligere partition vil blive brugt som datakilde.
Som indledende data, lad os tage et WordPress-websted med 40 GB mediefiler og en mysql-database. Da virtuelle servere varierer meget i egenskaber, og også for bedre reproducerbarhed, er her
servertestresultater ved hjælp af sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (ved hjælp af bundtet LuaJIT 2.1.0-beta3)
Kører testen med følgende muligheder:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra det aktuelle tidspunkt
Primtalsgrænse: 20000
Initialiserer arbejdertråde...
Tråde startet!
CPU hastighed:
hændelser per sekund: 836.69
gennemløb:
begivenheder/s (eps): 836.6908
forløbet tid: 30.0039s
Samlet antal begivenheder: 25104
Latens (ms):
min: 2.38
gennemsnit: 4.78
max: 22.39
95. percentil: 10.46
sum: 119923.64
Tråd retfærdighed:
hændelser (avg/stddev): 6276.0000/13.91
eksekveringstid (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 (ved hjælp af bundtet LuaJIT 2.1.0-beta3)
Kører testen med følgende muligheder:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra det aktuelle tidspunkt
Kører hukommelseshastighedstest med følgende muligheder:
blokstørrelse: 1KiB
samlet størrelse: 102400MiB
operation: læs
omfang: globalt
Initialiserer arbejdertråde...
Tråde startet!
Samlede operationer: 50900446 (1696677.10 pr. sekund)
49707.47 MiB overført (1656.91 MiB/sek.)
gennemløb:
begivenheder/s (eps): 1696677.1017
forløbet tid: 30.0001s
Samlet antal begivenheder: 50900446
Latens (ms):
min: 0.00
gennemsnit: 0.00
max: 24.01
95. percentil: 0.00
sum: 39106.74
Tråd retfærdighed:
hændelser (avg/stddev): 12725111.5000/137775.15
eksekveringstid (avg/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=skrivehukommelseskørsel
sysbench 1.1.0-18a9f86 (ved hjælp af bundtet LuaJIT 2.1.0-beta3)
Kører testen med følgende muligheder:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra det aktuelle tidspunkt
Kører hukommelseshastighedstest med følgende muligheder:
blokstørrelse: 1KiB
samlet størrelse: 102400MiB
operation: skrive
omfang: globalt
Initialiserer arbejdertråde...
Tråde startet!
Samlede operationer: 35910413 (1197008.62 pr. sekund)
35068.76 MiB overført (1168.95 MiB/sek.)
gennemløb:
begivenheder/s (eps): 1197008.6179
forløbet tid: 30.0001s
Samlet antal begivenheder: 35910413
Latens (ms):
min: 0.00
gennemsnit: 0.00
max: 16.90
95. percentil: 0.00
sum: 43604.83
Tråd retfærdighed:
hændelser (avg/stddev): 8977603.2500/233905.84
eksekveringstid (avg/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --tid=60 --file-blokstørrelse=4K --fil-total-size=1G filio-kørsel
sysbench 1.1.0-18a9f86 (ved hjælp af bundtet LuaJIT 2.1.0-beta3)
Kører testen med følgende muligheder:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra det aktuelle tidspunkt
Ekstra fil åbne flag: (ingen)
128 filer, 8MB hver
1GiB samlet filstørrelse
Blokstørrelse 4KiB
Antal IO-anmodninger: 0
Læse/skrive-forhold for kombineret tilfældig IO-test: 1.50
Periodisk FSYNC aktiveret, kalder fsync() hver 100 anmodninger.
Kalder fsync() i slutningen af testen, aktiveret.
Brug af synkron I/O-tilstand
Udfører tilfældig r/w test
Initialiserer arbejdertråde...
Tråde startet!
gennemløb:
læst: 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
gennemsnit: 0.27
max: 18.01
95. percentil: 1.08
sum: 238469.45
Denne note begynder et stort
serie af artikler om backup
- Backup, del 1: Hvorfor backup er nødvendig, en oversigt over metoder, teknologier
- Backup Del 2: Gennemgang og test af rsync-baserede sikkerhedskopieringsværktøjer
- Sikkerhedskopiering Del 3: Gennemgang og test af dobbelthed, dobbelthed, deja dup
- Backup Del 4: Gennemgang og test af zbackup, restic, borgbackup
- Backup Del 5: Test af bacula og veeam backup til linux
- Sikkerhedskopiering Del 6: Sammenligning af sikkerhedskopieringsværktøjer
- Backup Del 7: Konklusioner
Kilde: www.habr.com