🥇Säkerhetskopiering, del 1: Syfte, översikt av metoder och teknologier

Varför är det nödvändigt att göra säkerhetskopior? Utrustningen är mycket och mycket pålitlig, dessutom finns det "moln" som är mer pålitliga än fysiska servrar: vid rätt konfiguration överlever en "moln"-server lätt en krasch på en fysisk infrastrukturserver, och sett ur användarnas perspektiv kommer service-tiden att upplevas som en liten, knappt märkbar fördröjning. Dessutom kräver duplicering av information ofta att man betalar för "överskott" av CPU-tid, diskbelastning och nätverkstrafik.

Ett perfekt program fungerar snabbt, läcker inte minne, har inga sårbarheter och existerar inte.
—Okänd

Eftersom program fortfarande skrivs av utvecklare, och testprocessen ofta saknas, plus att mjukvara sällan levereras med "best practices" (vilka i sig också är program, och därmed inte perfekta), måste systemadministratörer oftast hantera uppgifter som låter korta men är innehållsrika: "återställ som det var", "få databasen att fungera normalt", "fungerar långsamt — vi rullar tillbaka", samt min favorit "jag vet inte vad, men fixera det".

Förutom logiska fel som beror på slarviga utvecklares arbete, eller en olycklig sammanställning, samt bristande kunskap eller förståelse för små detaljer i programvaruuppbyggnad — inklusive system- och gränssnitt, samt operativsystem, drivrutiner och firmware — finns det också andra fel. Till exempel litar de flesta utvecklare på runtime med helt bortglömda fysiska lagar, som fortfarande inte kan kringgås med hjälp av program. Detta inkluderar den oändliga pålitligheten hos diskundersystemet och generellt alla datalagringssystem (inklusive RAM och CPU-cache!), samt noll behandlingstid på processorn, brist på fel vid överföring över nätverket och vid bearbetning på processorn, och nätverksfördröjningar som är lika med 0. Man bör inte heller förakta den beryktade tidsfristen, för om man inte hinner till den — så blir det problem som är mer komplexa än detaljerna kring nätverks- och diskoperationer.

Hur ska man hantera problem som dyker upp plötsligt och hänger över värdefulla data? Det finns inget som kan ersätta levande utvecklare, och det är inte säkert att det kommer att vara möjligt att göra det närmaste tiden. Å andra sidan har endast några få projekt lyckats bevisa att programmet kommer att fungera som avsett, och det är helt osäkert om man kan ta och tillämpa bevisen på andra liknande projekt. Dessutom tar sådana bevis otroligt mycket tid och kräver speciella färdigheter och kunskaper, vilket praktiskt taget gör möjligheten att tillämpa dem minimal med tanke på deadlines. Vi har dessutom fortfarande inte lärt oss något om supersnabb, billig och oändligt pålitlig teknik för lagring, bearbetning och överföring av information. Sådana teknologier, om de överhuvudtaget existerar, finns oftast i form av koncept, eller — oftare — endast i science fiction-böcker och filmer.

Bra konstnärer kopierar, stora konstnärer snor.
—Pablo Picasso.

De mest framgångsrika lösningarna och förvånansvärt enkla idéer sker ofta där helt oförenliga, vid första anblick, koncept, teknologier, kunskaper och vetenskapsområden möts.

Till exempel har både fåglar och flygplan vingar, men trots den funktionella likheten — principen för deras verksamhet överensstämmer i vissa lägen, och tekniska problem löses på liknande sätt: ihåliga ben, användning av starka och lätta material, osv. — är resultaten helt olika, även om de är ganska lika. De bästa exemplen av teknik som vi observerar är också till stor del hämtade från naturen: hermetiska rum i fartyg och ubåtar är en direkt analogi med ringmaskar; uppbyggnaden av raid-matriser och kontroll av dataintegritet är en duplicering av DNA-kedjan; samt parorgan, oberoendet av olika organs arbete från CNS (automatisering av hjärtats arbete) och reflexer — autonoma system på Internet. Naturligtvis kan det vara riskabelt att ta och tillämpa färdiga lösningar ”rakt av”, men vem vet, kanske finns det inga andra lösningar.

Om man visste var man skulle falla — skulle man ha lagt ut halm!
—Belarusiskt folkordspråk

Alltså är säkerhetskopior livsviktiga för den som önskar:

Ha möjlighet att återställa sina system med minimala driftstopp, eller till och med utan dem.
Våga agera, för i händelse av misstag finns det alltid möjlighet till återställning.
Minimera konsekvenserna av avsiktlig dataskada.

Här är lite teori.

All klassificering är godtycklig. Naturen klassificerar inte. Vi klassificerar för att det är enklare för oss, och vi gör det baserat på data som vi också väljer godtyckligt.
—Jean Bruler

Oavsett den fysiska lagringsmetoden kan logisk datalagring grovt sett delas in efter två åtkomstmetoder: block- och filbaserad. Denna uppdelning har på senare tid blivit ganska suddig, eftersom det inte riktigt finns några helt block- eller filbaserade logiska lagringssystem. För enkelhets skull kommer vi dock att anta att det finns sådana.

Blocklagring innebär att det finns en fysisk enhet där data skrivs i fasta portioner, block. Åtkomsten till blocken sker via en viss adress, där varje block har en egen adress inom enheten.

En backup görs vanligtvis genom att kopiera datablok. För att säkerställa dataintegriteten vid kopieringen pausas skrivningen av nya block samt förändring av befintliga. Om vi tar en analogi från den vanliga världen, kan det liknas med ett skåp med identiska numrerade fack.

Filbaserad datalagring fungerar på ett logiskt sätt som liknar blocklagring och organiseras ofta ovanpå den. Väsentliga skillnader inkluderar hierarki i lagring och människovänliga namn. Det skiljs ut en abstraktion i form av en fil — ett namngivet datområde, samt en katalog — en speciell fil där beskrivningar och åtkomster till andra filer lagras. Filer kan förses med ytterligare metadata: skapelsedatum, åtkomstflaggor och liknande. Backup görs vanligtvis så här: man letar efter ändrade filer och kopierar dem sedan till en annan filbaserad lagring med samma struktur. Integriteten i data implementeras vanligtvis genom att se till att det inte finns några filer under skrivning. Metadata för filer säkerhetskopieras på liknande sätt. Den närmaste analogin är ett bibliotek där det finns sektioner med olika böcker och även en katalog med människovänliga namn på böcker.

På senare tid har man ibland beskrivit ett annat alternativ, som i princip var början på filbaserad datalagring och som har samma archaic drag: objektlagring av data.

Det skiljer sig från filbaserad lagring genom att det inte har fler än ett lager (platt schema), och filnamnen, även om de är läsbara av människor, är mer anpassade för maskinbearbetning. Vid säkerhetskopiering hanteras objektlagringssystem oftast som filsystem, men det finns ibland andra alternativ.

— Det finns två typer av systemadministratörer: de som inte gör säkerhetskopior och de som REDAN gör det.
— Egentligen finns det tre typer: det finns även de som kontrollerar att säkerhetskopiorna kan återställas.
—Okänd

Det är också viktigt att förstå att själva processen för dataskydd görs med hjälp av program, och därför har den alla de samma nackdelarna som alla andra program. För att minska (inte utesluta!) beroendet av mänskliga faktorer samt särdrag som för sig själva kanske inte påverkar mycket, men tillsammans kan ge en märkbar effekt, tillämpas den så kallade 3-2-1-regeln. Det finns många varianter på hur denna regel kan tolkas, men jag föredrar följande tolkning: man bör lagra 3 uppsättningar av samma data, 2 uppsättningar bör lagras i olika format, och 1 uppsättning bör finnas på en geografiskt avlägsen lagringsplats.

Med lagringsformat avses följande:

Om det finns ett beroende av den fysiska lagringsmetoden — ändra den fysiska metoden.
Om det finns ett beroende av den logiska lagringsmetoden — ändra den logiska metoden.

För att uppnå maximal effekt av 3-2-1-regeln rekommenderas att byta lagringsformat på båda sätten.

Ur synvinkeln av beredskapen hos en säkerhetskopiering för dess primära syfte — återställande av funktionalitet — skiljer man på "varma" och "kalda" säkerhetskopior. Varma säkerhetskopior skiljer sig från kalla säkerhetskopior endast på ett sätt: de är omedelbart redo att användas, medan kalla säkerhetskopior för återställning kräver vissa ytterligare åtgärder: avkryptering, extrahering från arkiv, etc.

Det är viktigt att inte förväxla heta och kalla kopior med online och offline kopior, som innebär fysisk isolering av data och som i grunden är en annan klassificering av backupsmetoder. En offline kopia – som inte är direkt ansluten till systemet där den behövs för återställning – kan vara både het och kall (sett ur perspektivet av beredskap för återställning). En online kopia kan vara direkt tillgänglig där den behövs för återställning och är oftast het, även om det också finns kalla kopior.

Dessutom är det viktigt att komma ihåg att själva processen för att skapa backup vanligtvis inte slutar med en enda backup, och det kan finnas ett ganska stort antal kopior. Därför är det nödvändigt att särskilja fullständiga säkerhetskopior, dvs. de som kan återställas oberoende av andra backupkopior, samt differentierade (inkrementella, differens, dekrementala osv.) kopior – de som inte kan återställas på egen hand och som kräver återställning av en eller flera andra backupkopior i förväg.

Differentiella inkrementella kopior syftar till att spara lagringsutrymme för backup. Därför skrivs endast de ändrade data från den senaste backupen till backupen.

Differentiella dekrementala kopior skapas med samma syfte, men på lite annat sätt: en fullständig backup görs, men endast skillnaden mellan den senaste kopian och den föregående lagras.

Det är värt att särskilt granska backupprocessen ovanpå lagring som stöder avsaknaden av dubbletter. Så om du skriver fullständiga säkerhetskopior ovanpå det, kommer endast skillnaden mellan säkerhetskopiorna att lagras, men återställningsprocessen kommer att ske på samma sätt som med en fullständig kopia och vara helt transparent.

Quis custodiet ipsos custodes?
(Vem vaktar vaktarna? — latin.)

Det är mycket obehagligt när det inte finns några backupkopior, men det är ännu värre om en backup verkar vara gjord, men när återställning görs visar det sig att den inte kan återställas, eftersom:

Integriteten för de ursprungliga uppgifterna har blivit skadad.
Lagringen med backupkopior är skadad.
Återställning sker ganska långsamt, och man kan inte använda data som är delvis återställda.

En korrekt uppbyggd backup-process måste ta hänsyn till sådana observationer, särskilt de första två.

Integriteten hos originaldata kan garanteras på flera sätt. De vanligaste metoderna är: a) skapande av kloner av filsystem på blocknivå, b) "frysning" av tillståndet i filsystemet, c) speciella blockenheter med versionslagring, d) sekventiell skrivning av filer eller block. Kontrollsummor används också för att säkerställa datakontroll vid återställning.

Skador på lagring kan också upptäckas med hjälp av kontrollsummor. En ytterligare metod är att använda specialiserade enheter, eller filsystem, där det inte går att ändra redan skrivna data, men där det går att lägga till nya.

För att påskynda återställningen används dataåterställning med flera processer för att återställa — förutsatt att det inte finns någon "flaskhals" i form av ett långsamt nätverk eller en seg diskystem. För att undvika situationen med delvis återställda data kan backup-processen delas upp i relativt små deluppgifter, var och en utförd separat. På så sätt kan man återställa funktionaliteten sekventiellt med en uppskattning av återställningstiden. Detta problem ligger oftast på den organisatoriska nivån (SLA), så vi går inte in på detta i detalj.

Den som verkligen kan kryddor är inte den som lägger till dem i varje maträtt, utan den som aldrig lägger till något överflödigt.
—V. Sinjavskij

Praktiken när det gäller använd programvara hos systemadministratörer kan variera, men de grundläggande principerna är på ett eller annat sätt desamma, särskilt:

Det rekommenderas starkt att använda färdiga lösningar.
Programmen bör fungera förutsägbart, det vill säga det får inte finnas några odokumenterade egenskaper eller flaskhalsar.
Inställningen av varje program ska vara så enkel att man inte behöver läsa manualen eller sammanfattningen varje gång.
Lösningen bör vara så universell som möjligt, eftersom servrar kan variera avsevärt i sin hårdvarukonfiguration.

För säkerhetskopiering från blockenheter finns följande vanliga program:

dd, känd bland veteraner inom systemadministration, samt liknande program (som dd_rescue, exempelvis).
Inbyggda program i vissa filsystem som skapar en avskrift (dump) av filsystemet.
Allsidiga verktyg, till exempel partclone.
Egenutvecklade, ofta proprietära lösningar, som till exempel NortonGhost och senare versioner.

För filsystem delvis kan säkerhetskopieringsuppgiften lösas med metoder som används för blockenheter, men uppgiften kan också lösa sig mer effektivt med hjälp av exempelvis:

Rsync, ett universellt program och protokoll för att synkronisera tillståndet av filsystem.
Inbyggda verktyg för arkivering (ZFS).
Tredjepartsverktyg för arkivering; den mest populära representanten är tar. Det finns även andra, som dar — ett alternativ till tar med fokus på moderna system.

Det är värt att nämna programvaruverktyg för att säkerställa datakonsistens vid säkerhetskopiering. Oftast används följande alternativ:

Montering av filsystemet i skrivskyddat läge (ReadOnly), eller frysing av filsystemet (freeze) — metoden är tillämplig i begränsad utsträckning.
Skapande av avskrifter av tillståndet för filsystemet eller blockenheten (LVM, ZFS).
Användning av tredjepartsverktyg för att skapa avskrifter, även i de fall där tidigare punkter inte kan uppfyllas av något skäl (program av typen hotcopy).
CopyOnWrite-tekniken, men den är oftast bunden till det använda filsystemet (BTRFS, ZFS).

Så, för en liten server måste en säkerhetskopieringsplan tillhandahållas som uppfyller följande krav:

Enkel att använda — inga särskilda åtgärder krävs för att arbeta, minimala åtgärder för att skapa och återställa kopior.
Universell — fungerar på både stora och små servrar; detta är viktigt vid ökning av antal servrar eller skalning.
Installeras med en paketförvaltare, eller med en till två kommandon av typen 'ladda ner och packa upp'.
Stabil - använder ett standardformat eller ett format som har funnits länge.
Snabbt i drift.

Kandidater som uppfyller kraven mer eller mindre:

rdiff-backup
rsnapshot
burp
duplicati
duplicity
deja dup
dar
zbackup
restic
borgbackup

Som testmiljö kommer en virtuell maskin (baserad på XenServer) att användas med följande specifikationer:

4 kärnor 2.5 GHz,
16 GB RAM,
50 GB hybridlagring (lagringssystem med SSD-cache på 20% av storleken på den virtuella disken) som ett separat virtuellt disk utan partitionering,
200 Mbit/s internetanslutning.

Som server för säkerhetskopior kommer en nästan identisk maskin användas, men med en hårddisk på 500 GB.

Operativsystemet är Centos 7 x64: standardpartitioneringen, en extra partition kommer att användas som datakälla.

Som källdata tar vi en WordPress-webbplats med mediefiler på 40 GB och en MySQL-databas. Eftersom virtuella servrar de skiljer sig mycket åt i specificeringarna, och för att uppnå bättre reproducerbarhet, här är

resultaten av servertestning med hjälp av sysbench.sysbench —threads=4 —time=30 —cpu-max-prime=20000 cpu run
sysbench 1.1.0-18a9f86 (använder inbyggd LuaJIT 2.1.0-beta3)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från nuvarande tid

Gräns för primtal: 20000

Initierar arbetstrådar…

Trådar startade!

CPU-hastighet:
händelser per sekund: 836.69

Genomströmning:
händelser/s (eps): 836.6908
tid som förflutit: 30.0039s
totalt antal händelser: 25104

Latens (ms):
min: 2.38
genomsnitt: 4.78
max: 22.39
95:e percentilen: 10.46
summa: 119923.64

Trådarnas rättvisa:
händelser (genomsnitt/stddev): 6276.0000/13.91
körtid (genomsnitt/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 (använder inbyggd LuaJIT 2.1.0-beta3)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från nuvarande tid

Kör minnestest med följande alternativ:
blockstorlek: 1KiB
total storlek: 102400MiB
operation: läs
omfång: global

Initierar arbetstrådar…

Trådar startade!

Totala operationer: 50900446 (1696677.10 per sekund)

49707.47 MiB överförd (1656.91 MiB/s)

Genomströmning:
händelser/s (eps): 1696677.1017
tid som förflutit: 30.0001s
totalt antal händelser: 50900446

Latens (ms):
min: 0.00
genomsnitt: 0.00
max: 24.01
95:e percentilen: 0.00
summa: 39106.74

Trådarnas rättvisa:
händelser (genomsnitt/stddev): 12725111.5000/137775.15
körtid (genomsnitt/stddev): 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 (använder inbyggd LuaJIT 2.1.0-beta3)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från nuvarande tid

Kör minnestest med följande alternativ:
blockstorlek: 1KiB
total storlek: 102400MiB
operation: skriv
omfång: global

Initierar arbetstrådar…

Trådar startade!

Totala operationer: 35910413 (1197008.62 per sekund)

35068.76 MiB överförd (1168.95 MiB/s)

Genomströmning:
händelser/s (eps): 1197008.6179
tid som förflutit: 30.0001s
totalt antal händelser: 35910413

Latens (ms):
min: 0.00
genomsnitt: 0.00
max: 16.90
95:e percentilen: 0.00
summa: 43604.83

Trådarnas rättvisa:
händelser (genomsnitt/stddev): 8977603.2500/233905.84
körtid (genomsnitt/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 (använder inbyggd LuaJIT 2.1.0-beta3)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från nuvarande tid

Extra filöppningsflaggor: (inga)
128 filer, 8MiB vardera
1GiB total filstorlek
Blockstorlek 4KiB
Antal I/O-förfrågningar: 0
Läs-/skrivförhållande för kombinerad slumpmässig I/O-test: 1.50
Periodisk FSYNC aktiverad, anropar fsync() var 100:e förfrågan.
Anropar fsync() i slutet av testet, Aktiverat.
Använder synkront I/O-läge
Utför slumpmässigt läs-/skrivtest
Initierar arbetstrådar…

Trådar startade!

Genomströmning:
läs: 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
genomsnitt: 0.27
max: 18.01
95:e percentilen: 1.08
summa: 238469.45

Denna anteckning inleder en stor

cykel av artiklar om säkerhetskopiering