Varför behöver du säkerhetskopiera? När allt kommer omkring är utrustningen väldigt, väldigt tillförlitlig, och dessutom finns det "moln" som är bättre i tillförlitlighet än fysiska servrar: med rätt konfiguration kan en "moln"-server lätt överleva felet på en fysisk infrastrukturserver, och från från tjänsteanvändarnas synvinkel kommer det att finnas ett litet, knappt märkbart hopp i tidstjänsten. Dessutom kräver duplicering av information ofta att man betalar för "extra" processortid, diskbelastning och nätverkstrafik.
Ett idealiskt program går snabbt, läcker inte minne, har inga hål och existerar inte.
-Okänd
Eftersom program fortfarande skrivs av proteinutvecklare, och det ofta inte finns någon testprocess, plus att program sällan levereras med "bästa metoder" (som i sig också är program och därför ofullkomliga), måste systemadministratörer oftast lösa problem som låter kortfattat men kortfattat: "återgå till hur det var", "för basen till normal drift", "jobbar långsamt - rulla tillbaka", och även min favorit "Jag vet inte vad, men fixa det".
Förutom logiska fel som uppstår som ett resultat av vårdslöst arbete av utvecklare, eller en kombination av omständigheter, såväl som ofullständig kunskap eller missförstånd av små funktioner i byggprogram - inklusive anslutning och system, inklusive operativsystem, drivrutiner och firmware - det finns även andra fel. De flesta utvecklare förlitar sig till exempel på runtime och glömmer helt bort fysiska lagar, som fortfarande är omöjliga att kringgå med hjälp av program. Detta inkluderar den oändliga tillförlitligheten hos diskundersystemet och i allmänhet alla datalagringsundersystem (inklusive RAM och processorcache!), och noll bearbetningstid på processorn och frånvaron av fel under överföring över nätverket och under bearbetning på processorn. processor och nätverkslatens, vilket är lika med 0. Du bör inte försumma den ökända deadline, för om du inte uppfyller den i tid kommer det att finnas problem som är värre än nyanserna av nätverks- och diskdrift.
Vad ska man göra med problem som stiger i full kraft och hänger över värdefull data? Det finns inget som kan ersätta levande utvecklare, och det är inte ett faktum att det kommer att vara möjligt inom en snar framtid. Å andra sidan har endast ett fåtal projekt lyckats bevisa att programmet kommer att fungera som det är tänkt, och det kommer inte nödvändigtvis att vara möjligt att ta och tillämpa bevisen på andra liknande projekt. Sådana bevis tar också mycket tid och kräver speciella färdigheter och kunskaper, och detta minimerar praktiskt taget möjligheten att använda dem med hänsyn till deadlines. Dessutom vet vi ännu inte hur man använder ultrasnabb, billig och oändligt pålitlig teknik för att lagra, bearbeta och överföra information. Sådana teknologier, om de finns, är i form av koncept, eller - oftast - bara i science fiction-böcker och filmer.
Bra artister kopierar, stora artister stjäl.
— Pablo Picasso.
De mest framgångsrika lösningarna och förvånansvärt enkla sakerna händer vanligtvis där koncept, teknologier, kunskaper och vetenskapsområden som är absolut oförenliga vid första anblicken möts.
Till exempel har fåglar och flygplan vingar, men trots den funktionella likheten - funktionsprincipen i vissa lägen är densamma, och tekniska problem löses på ett liknande sätt: ihåliga ben, användning av starka och lätta material, etc. - resultaten är helt olika, även om de är väldigt lika. De bästa exemplen vi ser i vår teknik är också till stor del lånade från naturen: fartygens och ubåtarnas trycksatta avdelningar är en direkt analogi med annelider; bygga raid-arrayer och kontrollera dataintegritet - duplicera DNA-kedjan; såväl som parade organ, oberoende av olika organs arbete från centrala nervsystemet (automatisering av hjärtat) och reflexer - autonoma system på Internet. Att ta och tillämpa färdiga lösningar "head-on" är förstås fyllt av problem, men vem vet, kanske finns det inga andra lösningar.
Hade jag bara vetat var du skulle falla så hade jag lagt ut sugrör!
— Vitryska folkordspråk
Detta innebär att säkerhetskopior är avgörande för dem som vill:
- Kunna återställa driften av dina system med minimal stilleståndstid, eller till och med utan det alls
- Agera djärvt, för i händelse av ett fel finns det alltid möjlighet till en återställning
- Minimera konsekvenserna av avsiktlig datakorruption
Här är en liten teori
Varje klassificering är godtycklig. Naturen klassificerar inte. Vi klassificerar eftersom det är bekvämare för oss. Och vi klassificerar efter data som vi också tar godtyckligt.
—Jean Bruler
Oavsett den fysiska lagringsmetoden kan logisk datalagring delas upp i två sätt att komma åt dessa data: block och fil. Denna uppdelning har nyligen varit mycket suddig, eftersom rent block, såväl som rent fil, logisk lagring inte existerar. Men för enkelhetens skull antar vi att de finns.
Blockdatalagring innebär att det finns en fysisk enhet där data skrivs i vissa fasta delar, block. Blocken nås på en viss adress; varje block har sin egen adress i enheten.
En säkerhetskopia görs vanligtvis genom att kopiera datablock. För att säkerställa dataintegriteten avbryts inspelningen av nya block, såväl som ändringar av befintliga, vid tidpunkten för kopiering. Om vi tar en analogi från den vanliga världen, är det närmast en garderob med identiska numrerade celler.
Fildatalagring baserad på den logiska enhetsprincipen ligger nära blocklagring och är ofta organiserad ovanpå. Viktiga skillnader är närvaron av en lagringshierarki och mänskligt läsbara namn. En abstraktion tilldelas i form av en fil - ett namngivet dataområde, såväl som en katalog - en speciell fil där beskrivningar och åtkomst till andra filer lagras. Filer kan förses med ytterligare metadata: skapandetid, åtkomstflaggor, etc. Säkerhetskopiering görs vanligtvis på detta sätt: de letar efter ändrade filer och kopierar dem sedan till en annan fillagring med samma struktur. Dataintegritet implementeras vanligtvis genom att det inte finns några filer som skrivs till. Filmetadata säkerhetskopieras på samma sätt. Den närmaste liknelsen är ett bibliotek, som har sektioner med olika böcker, och som även har en katalog med läsbara namn på böckerna.
Nyligen beskrivs ibland ett annat alternativ, varifrån i princip fildatalagring började, och som har samma ålderdomliga egenskaper: objektdatalagring.
Det skiljer sig från fillagring genom att det inte har mer än ett kapsling (platt schema), och filnamnen, även om de är läsbara för människor, är fortfarande mer lämpade för bearbetning av maskiner. Vid säkerhetskopiering behandlas objektlagring oftast på samma sätt som fillagring, men ibland finns det 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 också de som kontrollerar att säkerhetskopior kan återställas.-Okänd
Det är också värt att förstå att själva säkerhetskopieringen av data utförs av program, så det har alla samma nackdelar som alla andra program. Att ta bort (inte eliminera!) beroende av den mänskliga faktorn, samt egenskaper - som var för sig inte har någon stark effekt, men tillsammans kan ge en märkbar effekt - den s.k. regel 3-2-1. Det finns många alternativ för hur man ska dechiffrera det, men jag gillar följande tolkning bättre: 3 set av samma data måste lagras, 2 set måste lagras i olika format och 1 set måste lagras i en geografiskt avlägsen lagring.
Lagringsformatet ska förstås enligt följande:
- Om det finns ett beroende av den fysiska lagringsmetoden ändrar vi den fysiska metoden.
- Om det finns ett beroende av den logiska lagringsmetoden ändrar vi den logiska metoden.
För att uppnå maximal effekt av 3-2-1-regeln rekommenderas det att ändra lagringsformatet på båda sätten.
Ur synvinkeln av beredskapen hos en säkerhetskopia för dess avsedda syfte - återställning av funktionalitet - görs en skillnad mellan "heta" och "kalla" säkerhetskopior. Heta skiljer sig från kalla på bara en sak: de är omedelbart klara för användning, medan kalla kräver några ytterligare steg för återställning: dekryptering, extrahering från arkivet, etc.
Förväxla inte varma och kalla kopior med online- och offlinekopior, vilket innebär fysisk isolering av data och i själva verket är ett annat tecken på klassificeringen av säkerhetskopieringsmetoder. Så en offlinekopia - inte direkt ansluten till systemet där den behöver återställas - kan vara antingen varm eller kall (när det gäller beredskap för återställning). En onlinekopia kan finnas tillgänglig direkt där den behöver restaureras, och oftast är det varmt, men det finns även kalla.
Dessutom, glöm inte att processen att skapa säkerhetskopior i sig själv vanligtvis inte slutar med skapandet av en säkerhetskopia, och det kan finnas ett ganska stort antal kopior. Därför är det nödvändigt att skilja på fullständiga säkerhetskopior, d.v.s. de som kan återställas oberoende av andra säkerhetskopior, såväl som differentiella (inkrementella, differentiella, dekrementella, etc.) kopior - de som inte kan återställas oberoende och kräver preliminär återställning av en eller flera andra säkerhetskopior.
Differentiella inkrementella säkerhetskopieringar är ett försök att spara backuplagringsutrymme. Således skrivs endast ändrad data från den tidigare säkerhetskopian till säkerhetskopian.
Differentiella dekrementella skapas för samma ändamål, men på ett lite annorlunda sätt: en fullständig säkerhetskopia görs, men bara skillnaden mellan den färska kopian och den föregående lagras faktiskt.
Separat är det värt att överväga processen för säkerhetskopiering över lagring, vilket stöder frånvaron av lagring av dubbletter. Således, om du skriver fullständiga säkerhetskopior ovanpå det, kommer bara skillnaderna mellan säkerhetskopiorna att faktiskt skrivas, men processen för att återställa säkerhetskopiorna kommer att likna återställning från en fullständig kopia och helt transparent.
Vill du ha ipsos custodes?
(Vem ska vakta väktarna själva? - lat.)
Det är väldigt obehagligt när det inte finns några säkerhetskopior, men det är mycket värre om en säkerhetskopia verkar ha gjorts, men vid återställning visar det sig att den inte kan återställas eftersom:
- Integriteten för källdata har äventyrats.
- Säkerhetskopieringslagringen är skadad.
- Återställning fungerar mycket långsamt, du kan inte använda data som delvis har återställts.
En korrekt konstruerad säkerhetskopieringsprocess måste ta hänsyn till sådana kommentarer, särskilt de två första.
Källdatas integritet kan garanteras på flera sätt. De vanligaste är följande: a) skapa ögonblicksbilder av filsystemet på blocknivå, b) "frysa" filsystemets tillstånd, c) en speciell blockenhet med versionslagring, d) sekventiell inspelning av filer eller block. Kontrollsummor tillämpas också för att säkerställa att data verifieras under återställning.
Lagringskorruption kan också upptäckas med hjälp av kontrollsummor. En ytterligare metod är användningen av specialiserade enheter eller filsystem där redan inspelade data inte kan ändras, men nya kan läggas till.
För att snabba på återställningen används dataåterställning med flera processer för återställning – förutsatt att det inte finns någon flaskhals i form av ett långsamt nätverk eller långsamt disksystem. För att komma runt situationen med delvis återställd data kan du dela upp säkerhetskopieringsprocessen i relativt små deluppgifter, som var och en utförs separat. Således blir det möjligt att konsekvent återställa prestanda samtidigt som man förutsäger återhämtningstiden. Detta problem ligger oftast i organisationsplanet (SLA), så vi kommer inte att uppehålla oss vid detta i detalj.
En expert på kryddor är inte den som tillsätter dem till varje rätt, utan den som aldrig tillför något extra till det.
-I. Sinyavsky
Praxis för programvaran som används av systemadministratörer kan variera, men de allmänna principerna är fortfarande, på ett eller annat sätt, desamma, i synnerhet:
- Det rekommenderas starkt att använda färdiga lösningar.
- Program ska fungera förutsägbart, d.v.s. Det ska inte finnas några odokumenterade funktioner eller flaskhalsar.
- Att ställa in varje program ska vara så enkelt att du inte behöver läsa manualen eller fuskbladet varje gång.
- Om möjligt bör lösningen vara universell, eftersom servrar kan variera mycket i sina hårdvaruegenskaper.
Det finns följande vanliga program för att ta säkerhetskopior från blockerade enheter:
- dd, som är bekant för veteraner från systemadministration, inkluderar även liknande program (samma dd_rescue, till exempel).
- Verktyg inbyggda i vissa filsystem som skapar en dump av filsystemet.
- Allätande verktyg; till exempel partclone.
- Egna, ofta proprietära, beslut; till exempel NortonGhost och senare.
För filsystem är säkerhetskopieringsproblemet delvis löst med metoder som är tillämpliga för blockenheter, men problemet kan lösas mer effektivt med till exempel:
- Rsync, ett allmänt program och protokoll för att synkronisera filsystemens tillstånd.
- Inbyggda arkiveringsverktyg (ZFS).
- Tredje parts arkiveringsverktyg; den mest populära representanten är tjära. Det finns andra, till exempel dar - en ersättning för tjära som syftar till moderna system.
Det är värt att nämna separat om mjukvaruverktyg för att säkerställa datakonsistens när du skapar säkerhetskopior. De vanligaste alternativen är:
- Montera filsystemet i skrivskyddat läge (ReadOnly), eller frysa filsystemet (frysa) - metoden är av begränsad tillämplighet.
- Skapa ögonblicksbilder av tillståndet för filsystem eller blockenheter (LVM, ZFS).
- Användningen av verktyg från tredje part för att organisera intryck, även i fall där de tidigare punkterna inte kan tillhandahållas av någon anledning (program som hotcopy).
- Kopiera-på-ändring-tekniken (CopyOnWrite), men den är oftast knuten till det filsystem som används (BTRFS, ZFS).
Så för en liten server måste du tillhandahålla ett säkerhetskopieringsschema som uppfyller följande krav:
- Lätt att använda - inga speciella ytterligare steg krävs under drift, minimala steg för att skapa och återställa kopior.
- Universal - fungerar på både stora och små servrar; detta är viktigt när man ökar antalet servrar eller skalning.
- Installerad av en pakethanterare, eller i ett eller två kommandon som "ladda ner och packa upp".
- Stabil - ett standard eller sedan länge etablerat lagringsformat används.
- Snabb i jobbet.
Sökande från de som mer eller mindre uppfyller kraven:
- rdiff-backup
- rsnapshot
- rapa
- duplicering
- falskhet
- låt dup
- ge
- zbackup
- restisk
- borgbackup
En virtuell maskin (baserad på XenServer) med följande egenskaper kommer att användas som en testbänk:
- 4 kärnor 2.5 GHz,
- 16 GB RAM,
- 50 GB hybridlagring (lagringssystem med cachning på SSD 20% av den virtuella diskstorleken) i form av en separat virtuell disk utan partitionering,
- 200 Mbps Internetkanal.
Nästan samma maskin kommer att användas som backup-mottagare, bara med en 500 GB hårddisk.
Operativsystem - Centos 7 x64: standardpartition, ytterligare partition kommer att användas som datakälla.
Som första data, låt oss ta en WordPress-webbplats med 40 GB mediefiler och en mysql-databas. Eftersom virtuella servrar varierar mycket i egenskaper, och även för bättre reproducerbarhet, här är
servertestresultat med sysbench.sysbench --threads=4 --time=30 --cpu-max-prime=20000 cpu körning
sysbench 1.1.0-18a9f86 (med medföljande LuaJIT 2.1.0-beta3)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från aktuell tid
Gräns för primtal: 20000 XNUMX
Initierar arbetartrådar...
Trådar igång!
CPU-hastighet:
händelser per sekund: 836.69
genomströmning:
händelser/s (eps): 836.6908
förfluten tid: 30.0039s
Totalt antal evenemang: 25104
Latens (ms):
min: 2.38
medel: 4.78
max: 22.39
95:e percentilen: 10.46
summa: 119923.64
Trådens rättvisa:
händelser (avg/stddev): 6276.0000/13.91
exekveringstid (avg/stddev): 29.9809/0.01
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=läs minneskörning
sysbench 1.1.0-18a9f86 (med medföljande LuaJIT 2.1.0-beta3)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från aktuell tid
Kör minneshastighetstest med följande alternativ:
blockstorlek: 1KiB
total storlek: 102400MiB
operation: läs
omfattning: global
Initierar arbetartrådar...
Trådar igång!
Totala operationer: 50900446 (1696677.10 per sekund)
49707.47 MiB överförd (1656.91 MiB/sek)
genomströmning:
händelser/s (eps): 1696677.1017
förfluten tid: 30.0001s
Totalt antal evenemang: 50900446
Latens (ms):
min: 0.00
medel: 0.00
max: 24.01
95:e percentilen: 0.00
summa: 39106.74
Trådens rättvisa:
händelser (avg/stddev): 12725111.5000/137775.15
exekveringstid (avg/stddev): 9.7767/0.10
sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=skrivminneskörning
sysbench 1.1.0-18a9f86 (med medföljande LuaJIT 2.1.0-beta3)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från aktuell tid
Kör minneshastighetstest med följande alternativ:
blockstorlek: 1KiB
total storlek: 102400MiB
operation: skriva
omfattning: global
Initierar arbetartrådar...
Trådar igång!
Totala operationer: 35910413 (1197008.62 per sekund)
35068.76 MiB överförd (1168.95 MiB/sek)
genomströmning:
händelser/s (eps): 1197008.6179
förfluten tid: 30.0001s
Totalt antal evenemang: 35910413
Latens (ms):
min: 0.00
medel: 0.00
max: 16.90
95:e percentilen: 0.00
summa: 43604.83
Trådens rättvisa:
händelser (avg/stddev): 8977603.2500/233905.84
exekveringstid (avg/stddev): 10.9012/0.41
sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G filio körning
sysbench 1.1.0-18a9f86 (med medföljande LuaJIT 2.1.0-beta3)
Kör testet med följande alternativ:
Antal trådar: 4
Initierar slumptalsgenerator från aktuell tid
Extra filöppningsflaggor: (inga)
128 filer, 8MB vardera
1 GiB total filstorlek
Blockstorlek 4KiB
Antal IO-förfrågningar: 0
Läs/skriv-förhållande för kombinerat slumpmässigt IO-test: 1.50
Periodisk FSYNC aktiverad, anropar fsync() var 100:e begäran.
Anropar fsync() i slutet av testet, aktiverat.
Använder synkront I/O-läge
Gör ett slumpmässigt r/w-test
Initierar arbetartrådar...
Trådar igång!
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
medel: 0.27
max: 18.01
95:e percentilen: 1.08
summa: 238469.45
Denna anteckning börjar en stor
serie artiklar om säkerhetskopiering
- Backup, del 1: Varför säkerhetskopiering behövs, en översikt över metoder, teknologier
- Säkerhetskopiering Del 2: Granskning och testning av rsync-baserade säkerhetskopieringsverktyg
- Säkerhetskopiering del 3: Granskning och testning av dubbelhet, duplikat, deja dup
- Backup Del 4: Granskning och testning av zbackup, restic, borgbackup
- Backup del 5: Testar bacula och veeam backup för linux
- Säkerhetskopiering Del 6: Jämföra säkerhetskopieringsverktyg
- Backup Del 7: Slutsatser
Källa: will.com