Hvorfor er det nødvendigt at lave sikkerhedskopier? Udstyret er trods alt meget pålideligt, og der er desuden 'cloud-løsninger', der ofte er mere pålidelige end fysiske servere: med den rette opsætning kan en 'cloud'-server nemt overleve et nedbrud af en fysisk server, og for brugerne vil der kun være en lille, knap mærkbar forøgelse i svartiden. Desuden kræver dublering af oplysninger ofte betaling for 'overflødig' CPU-tid, diskbelastning og netværkstrafik.
Det perfekte program kører hurtigt, lækker ikke hukommelse, har ingen huller og findes ikke.
—Ukendt
Da programmer stadig bliver skrevet af menneskelige udviklere, og testprocessen ofte er mangelfuld, plus at levering af programmer sjældent sker i overensstemmelse med 'best practices' (som i sig selv er programmer og derfor ikke perfekte), bliver systemadministratorer ofte tvunget til at løse opgaver, der lyder korte, men er meget præcise: 'tilbage som det var', 'bring databasen tilbage til normal drift', 'langsomt — vi ruller tilbage', samt min favorit 'jeg ved ikke hvad, men lav det'.
Ud over logiske fejl, der opstår som følge af uagtsomhed fra udviklerne eller omstændighederne, samt mangelfuld viden eller forståelse af små nuancer i programopbygning — inklusive bindingslag og systemlag, herunder operativsystemer, drivere og firmware — findes der også andre fejl. For eksempel stoler de fleste udviklere på runtime, og helt glemmer de fysiske love, som stadig ikke kan omgås med programmer. Dette inkluderer den uendelige pålidelighed af diskundersystemet og generelt enhver lagringsundersystem (inklusive RAM og processor-cache!), null behandlingstid på CPU'en, og fraværet af fejl ved netværksoverførsel og procesbehandling, samt netværksforsinkelser, der er lig med 0. Man skal ikke undervurdere den berygtede deadline, for hvis den ikke overholdes — vil der opstå problemer, der er mere indviklede end nuancerne i netværks- og diskdrift.
Hvordan skal man håndtere de problemer, der rejser sig foran os og truer med at skade vigtige data? Der er ingen erstatning for levende udviklere, og der er ingen garanti for, at man kan finde dem i den nærmeste fremtid. På den anden side har kun få projekter været i stand til at bevise, at programmerne vil fungere som planlagt, og det er ikke nødvendigvis muligt at anvende disse beviser på andre, lignende projekter. Desuden tager sådanne beviser lang tid at etablere og kræver særlige færdigheder og viden, hvilket næsten minimerer muligheden for deres anvendelse i lyset af deadlines. Vi mestrer heller ikke en hurtig, billig og uendelig pålidelig teknologi til opbevaring, behandling og overførsel af information. Sådanne teknologier, hvis de eksisterer, findes oftest kun i konceptfaser eller, oftere, i sci-fi bøger og film.
Gode kunstnere kopierer, store kunstnere stjæler.
—Pablo Picasso.
De mest vellykkede løsninger og de overraskende enkle ting opstår ofte der, hvor fuldstændig uforenelige begreber, teknologier, viden eller videnskabsområder mødes.
For eksempel har både fugle og flyvninger vinger, men på trods af den funktionelle lighed — i nogle driftsformer er principperne ens, og tekniske problemer løses på lignende måder: hule knogler, brug af stærke og lette materialer osv. — er resultaterne helt forskellige, selvom de er ret ensartede. De bedste eksempler, vi ser i vores teknologi, er også i høj grad lånt fra naturen: tætsluttende kamre i skibe og ubåde er direkte analogier med ringorme; opbygning af RAID-array og kontrol af dataintegritet — duplikering af DNA-strenge; samt parrede organer, uafhængigheden af forskellige organers funktion fra CNS (automatisk hjertefunktion) og reflekser — autonome systemer i internettet. Selvfølgelig kan det være problematisk at anvende færdige løsninger direkte, men hvem ved, måske er der heller ikke andre løsninger.
Hvis man vidste, hvor man ville falde, ville man have lagt halm ud!
—Hvidrussisk folkeord.
Det betyder, at sikkerhedskopier er livsvigtige for dem, der ønsker:
- At kunne genoprette driften af deres systemer med minimal nedetid, eller endda uden.
- Handle things boldly, because in case of an error, there is always an option to roll back.
- Minimize the consequences of deliberate data corruption.
Here is a bit of theory.
Any classification is arbitrary. Nature does not classify. We classify because it is more convenient for us. And we classify based on data that we also take arbitrarily.
—Jean Bruyère
Regardless of the physical method of storage, logical data storage can be conditionally divided into two access methods: block and file. This division has recently become quite blurred, as there are no purely block or purely file logical storages. However, for simplicity, we will consider that they exist.
Block data storage implies that there is a physical device where data is written in fixed portions, or blocks. Access to blocks is done by some address; each block corresponds to its address within the device.
A backup is usually made by copying blocks of data. To ensure data integrity at the time of copying, the writing of new blocks is paused, as well as changes to existing ones. If we take an analogy from the ordinary world - it is closest to a cabinet with identically numbered cells.
File data storage, in terms of logical devices, is close to block storage and is often organized on top. Important differences include the presence of a storage hierarchy and human-readable names. An abstraction is distinguished in the form of a file — a named data area, as well as a directory — a special file that contains descriptions and access to other files. Files can be supplemented with additional metadata: creation time, access flags, etc. Backups are usually done by searching for modified files, then copying them into another file storage with the same structure. Data integrity is generally achieved by the absence of files that are being written to. File metadata is backed up similarly. The closest analogy is a library, which has sections with different books, and also has a catalog with human-readable book titles.
På det seneste beskrives der sommetider en anden variant, som reelt set er begyndelsen på filopbevaring og som har de samme forældede træk: objektbaseret datalagring.
Det adskiller sig fra filopbevaring ved, at det ikke har dybdegående lag, mere end én (flad struktur), og filnavne, selvom de er menneskeligt læselige, er mere tilpasset til maskinbehandling. Ved backup behandles objektlagre ofte på samme måde som filopbevaring, men der er lejlighedsvis andre muligheder.
— Der er to slags systemadministratorer, dem der ikke laver backups, og dem der allerede gør.
— I virkeligheden er der tre slags: der er også dem, der tjekker, at backups kan gendannes.—Ukendt
Det er også vigtigt at forstå, at selve backup-processen udføres af programmer, så den har alle de samme ulemper som ethvert andet program. For at reducere (ikke eliminere!) afhængigheden af menneskelig faktorer, samt af særlige forhold — som hver for sig ikke direkte påvirker, men som samlet set kan give en mærkbar effekt — anvendes den såkaldte 3-2-1 regel. Der er mange måder at tolke den på, men jeg kan bedst lide den følgende forklaring: man skal opbevare 3 sæt af de samme data, 2 sæt skal opbevares i forskellige formater, og 1 sæt skal opbevares geografisk adskilt.
Med lagringsformat menes følgende:
- Hvis der er afhængighed af den fysiske lagringsmetode — så ændrer vi den fysiske metode.
- Hvis der er afhængighed af den logiske lagringsmetode — så ændrer vi den logiske metode.
For at opnå maksimal effekt af 3-2-1-reglen anbefales det at ændre lagringsformatet på begge måder.
Set fra perspektivet af backupens beredskab til dens primære formål — gendannelse af funktionalitet — skelnes der mellem "aktive" og "passive" backups. Aktive backups adskiller sig fra passive backups ved kun én ting: de er straks klar til brug, mens passive backups kræver visse yderligere handlinger for gendannelse: dekryptering, udtrækning fra arkiver, osv.
Man bør ikke forveksle varme og kolde kopier med online og offline kopier, som indebærer fysisk isolering af data, og som i bund og grund er en anden klassifikation af backup-metoder. En offline-kopi – der ikke er direkte tilsluttet systemet, hvor den skal gendannes – kan både være varm og kold (set ud fra gendannelsesparathed). En online-kopi kan være direkte tilgængelig, hvor den skal gendannes, og er oftest en varm kopi, men der findes også kolde kopier.
Derudover bør man ikke glemme, at selve processen med at lave backups normalt ikke slutter med at lave én backup, og der kan være et betydeligt antal kopier. Derfor skal man skelne mellem komplette sikkerhedskopier, dvs. dem der kan gendannes uafhængigt af andre sikkerhedskopier, samt differentielle (inkrementelle, differentielle, dekrementale osv.) kopier – de, der ikke kan gendannes autonomt og kræver forudgående gendannelse af en eller flere andre sikkerhedskopier.
Differentielle inkrementelle kopier – et forsøg på at spare plads til opbevaring af backups. Således skrives kun de ændrede data fra den forrige backup ind i backup-filen.
Differentielle dekrementale oprettes med det samme mål, men lidt anderledes: der laves en komplet backup, men der gemmes faktisk kun forskellen mellem den friske kopi og den tidligere.
Det er også værd at overveje backup-processen over et lager, der understøtter fravær af duplikater. Således vil hvis man skriver komplette backups over det, kun forskellen mellem backup-kopierne faktisk blive gemt, men processen med at gendanne backups vil ske ligesom gendannelse fra en fuld kopi og være helt gennemsigtig.
Quis custodiet ipsos custodes?
(Hvem vogter vogterne selv? — latin.)
Det er meget ubehageligt, når der ikke findes nogle backups, men det er meget værre, hvis en backup tilsyneladende er lavet, men ved gendannelse viser det sig, at den ikke kan gendannes, fordi:
- Integriteten af de oprindelige data var blevet kompromitteret.
- Lageret med backups er beskadiget.
- Gendannelse sker ret langsomt, og data, der er delvist gendannet, kan ikke anvendes.
Den korrekt opbyggede backup-proces bør tage sådanne bemærkninger i betragtning, især de første to.
Integriteten af de oprindelige data kan garanteres på flere måder. De mest almindelige er: a) oprettelse af snapshots af filsystemet på blokniveau, b) "frysning" af tilstanden af filsystemet, c) særlige blok-enheder med versionering, d) sekventiel skrivning af filer eller blokke. Kontrolsummer anvendes også for at sikre datavalidering under gendannelsen.
Skader på lageret kan også opdages ved hjælp af kontrolsummer. En yderligere metode er anvendelse af specialiserede enheder eller filsystemer, hvor man ikke kan ændre allerede skrevne data, men kan tilføje nye.
For at fremskynde gendannelsen anvendes datagendannelse med flere processer – forudsat at der ikke er en "flaskehals" i form af et langsomt netværk eller et ikke hurtig disk-system. For at omgå situationen med delvist gendannede data kan backup-processen opdeles i forholdsvis små delopgaver, som udføres separat. Dette giver mulighed for sekventielt at gendanne funktionaliteten med en forudsigelse af gendannelsestiden. Dette problem relaterer sig ofte til organisatoriske forhold (SLA), så vi vil ikke gå ind i detaljerne.
Den, der virkelig forstår krydderier, tilføjer ikke dem til hver ret, men den, der aldrig vil tilføre noget overflødigt til dem.
—V. Sinyavsky
Praksis med hensyn til det anvendte software kan variere blandt systemadministratorer, men de grundlæggende principper er alligevel de samme, herunder:
- Det anbefales kraftigt at anvende færdige løsninger.
- Programmer skal fungere forudsigeligt, dvs. der bør ikke være uhåndterede funktioner eller flaskehalse.
- Indstillingen af hvert program skal være så enkel, at man ikke hver gang behøver at læse vejledningen eller en huskeseddel.
- Løsningen skal være universel, da servere kan variere betydeligt i deres hardware-specifikationer.
For at tage sikkerhedskopier fra blokapparater er de følgende programmer almindeligt anvendt:
- dd, kendt af veteraner inden for systemadministration, samt lignende programmer (f.eks. dd_rescue).
- Indbyggede værktøjer i visse filsystemer, der skaber et dump af filsystemet.
- Generelle værktøjer; for eksempel partclone.
- Egne, ofte proprietary løsninger; for eksempel Norton Ghost og nyere versioner.
For filsystemer delvist løses backupopgaven ved hjælp af metoder, der kan anvendes på blokapparater, men opgaven kan også løses mere effektivt ved at bruge f.eks.:
- Rsync, et universelt program og protokol til synkronisering af tilstanden af filsystemer.
- Indbyggede værktøjer til arkivering (ZFS).
- Tredjeparts værktøjer til arkivering; den mest populære repræsentant er tar. Der findes også andre, f.eks. dar — en erstatning for tar, der er tilpasset moderne systemer.
Det er vigtigt at nævne software til at sikre datakonsistens ved oprettelse af sikkerhedskopier. De mest almindelige metoder er:
- Montering af filsystemet i skrivebeskyttet tilstand (ReadOnly) eller fryse filsystemet (freeze) — metoden er begrænset anvendelig.
- Oprettelse af snapshots af tilstanden af filsystemet eller blokapparatet (LVM, ZFS).
- Brug af tredjeparts værktøjer til at organisere snapshots, også når de foregående metoder ikke kan anvendes af en eller anden grund (programmer som hotcopy).
- CopyOnWrite-teknik, men den er ofte knyttet til det anvendte filsystem (BTRFS, ZFS).
Så for en lille server skal der sikres en backup-løsning, der opfylder følgende krav:
- Nem at bruge — kræver ikke særlige handlinger under drift, minimale handlinger til oprettelse og genopretning af kopier.
- Universel — fungerer både på store og små servere; dette er vigtigt ved vækst i antallet servere eller skalering.
- Installeres via pakkeforvalteren, eller i en til to kommandoer som "download og udpak".
- Stabilt – bruger et standardformat eller et velkendt lagringsformat.
- Hurtig i drift.
Kandidater, der mere eller mindre opfylder kravene:
- rdiff-backup
- rsnapshot
- burp
- duplicati
- duplicity
- deja dup
- dar
- zbackup
- restic
- borgbackup
Som testmiljø vil der blive brugt en virtuel maskine (baseret på XenServer) med følgende specifikationer:
- 4 kerner 2.5 GHz,
- 16 GB RAM,
- 50 GB hybridopbevaring (Lager med SSD-cache på 20% af størrelsen på den virtuelle disk) som en separat virtuel disk uden partitionering,
- 200 Mbit/s internetforbindelse.
Som backup-server anvendes en næsten identisk maskine, men med en harddisk på 500 GB.
Operativsystem – CentOS 7 x64: standardpartitionering, en ekstra partition vil blive brugt som datakilde.
Som udgangsdata vil vi tage en wordpress-webside med mediefiler på 40 GB og en database på MySQL. Da virtuelle servere der er betydelige forskelle i specifikationerne, og for bedre reproducerbarhed er der
testresultater af serveren ved hjælp af sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (bruger den medfølgende LuaJIT 2.1.0-beta3)
Kører testen med følgende indstillinger:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra nuværende tid
Grænse for primtalsberegning: 20000
Initialiserer arbejdertråde…
Tråde startet!
CPU-hastighed:
begivenheder pr. sekund: 836.69
Gennemstrømning:
begivenheder/s (eps): 836.6908
tid forløbet: 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åde fairness:
begivenheder (gennemsnit/stdafvigelse): 6276.0000/13.91
udførelsestid (gennemsnit/stdafvigelse): 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 (bruger den medfølgende LuaJIT 2.1.0-beta3)
Kører testen med følgende indstillinger:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra nuværende tid
Kører hastighedstest for hukommelse med følgende indstillinger:
blokstørrelse: 1KiB
total størrelse: 102400MiB
operation: læs
område: global
Initialiserer arbejdertråde…
Tråde startet!
Samlede operationer: 50900446 (1696677.10 pr. sekund)
49707.47 MiB overført (1656.91 MiB/s)
Gennemstrømning:
begivenheder/s (eps): 1696677.1017
tid forløbet: 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åde fairness:
begivenheder (gennemsnit/stdafvigelse): 12725111.5000/137775.15
udførelsestid (gennemsnit/stdafvigelse): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run
sysbench 1.1.0-18a9f86 (bruger den medfølgende LuaJIT 2.1.0-beta3)
Kører testen med følgende indstillinger:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra nuværende tid
Kører hastighedstest for hukommelse med følgende indstillinger:
blokstørrelse: 1KiB
total størrelse: 102400MiB
operation: skriv
område: global
Initialiserer arbejdertråde…
Tråde startet!
Samlede operationer: 35910413 (1197008.62 pr. sekund)
35068.76 MiB overført (1168.95 MiB/s)
Gennemstrømning:
begivenheder/s (eps): 1197008.6179
tid forløbet: 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åde fairness:
begivenheder (gennemsnit/stdafvigelse): 8977603.2500/233905.84
udførelsestid (gennemsnit/stdafvigelse): 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 (bruger den medfølgende LuaJIT 2.1.0-beta3)
Kører testen med følgende indstillinger:
Antal tråde: 4
Initialiserer tilfældig talgenerator fra nuværende tid
Ekstra filåbningsflag: (ingen)
128 filer, 8MiB hver
1GiB samlet filstørrelse
Blokstørrelse 4KiB
Antal IO-anmodninger: 0
Læse-/skrivforhold for kombineret random IO-test: 1.50
Periodisk FSYNC aktiveret, kalder fsync() hver 100 anmodninger.
Kalder fsync() ved testens afslutning, aktiveret.
Bruger synkron I/O-tilstand
Udfører tilfældig r/w test
Initialiserer arbejdertråde…
Tråde startet!
Gennemstrømning:
læse: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
skrive: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latens (ms):
min: 0.00
gennemsnit: 0.27
maks: 18.01
95. percentile: 1.08
sum: 238469.45
Denne note markerer begyndelsen på en stor
cyklus af artikler om backup
- Sikkerhedskopiering, del 1: Hvorfor er sikkerhedskopiering nødvendigt, oversigt over metoder, teknologier
- Backup, del 2: Oversigt og test af rsync-baserede backupløsninger.
- Sikkerhedskopiering, del 3: Oversigt og test af duplicity, duplicaty, deja dup
- Sikkerhedskopiering, del 4: Oversigt og test af zbackup, restic, borgbackup
- Sikkerhedskopiering, del 5: Test af bacula og veeam backup for linux
- Sikkerhedskopiering, del 6: Sammenligning af sikkerhedskopieringsværktøjer
- Backup, del 7: Konklusioner
Kilde: habr.com
