Denna notering avslutar cykeln om säkerhetskopiering. Den kommer att diskutera den logiska organisationen av en dedikerad server (eller VPS), bekväm för säkerhetskopiering, och kommer också att erbjuda ett alternativ för att snabbt återställa en server från en säkerhetskopia utan mycket stillestånd i händelse av en katastrof.
Rå data
En dedikerad server har oftast minst två hårddiskar som tjänar till att organisera en RAID-array (spegel) på första nivån. Detta är nödvändigt för att kunna fortsätta driva servern om en disk går sönder. Om detta är en vanlig dedikerad server kan det finnas en separat hårdvaru-RAID-kontroller med aktiv cachningsteknik på SSD, så att förutom vanliga hårddiskar kan en eller flera SSD-enheter anslutas. Ibland erbjuds dedikerade servrar, där de lokala diskarna endast innehåller SATADOM (små diskar, strukturellt sett en flashenhet ansluten till en SATA-port), eller till och med en vanlig liten (8-16GB) flashenhet ansluten till en speciell intern port, och data tas från lagringssystemet , anslutet via ett dedikerat lagringsnätverk (Ethernet 10G, FC, etc.), och det finns dedikerade servrar som laddas direkt från lagringssystemet. Jag kommer inte att överväga sådana alternativ, eftersom uppgiften att säkerhetskopiera servern smidigt övergår till specialisten som underhåller lagringssystemet; vanligtvis finns det olika proprietära tekniker för att skapa ögonblicksbilder, inbyggd deduplicering och andra glädjeämnen för systemadministratören , diskuterat i de tidigare delarna av denna serie. Volymen på en dedikerad servers diskarray kan nå flera tiotals terabyte, beroende på antalet och storleken på diskar som är anslutna till servern. När det gäller VPS är volymerna mer blygsamma: vanligtvis inte mer än 100GB (men det finns också fler), och tarifferna för sådan VPS kan lätt bli dyrare än de billigaste dedikerade servrarna från samma värd. En VPS har oftast en disk, eftersom det kommer att finnas ett lagringssystem (eller något hyperkonvergerat) under den. Ibland har en VPS flera diskar med olika egenskaper, för olika ändamål:
- litet system - för att installera operativsystemet;
- stor - lagra användardata.
När du installerar om systemet med hjälp av kontrollpanelen skrivs inte disken med användardata över, utan systemdisken är helt påfylld. Dessutom, i fallet med en VPS, kan värddatorn erbjuda en knapp som tar en ögonblicksbild av tillståndet för VPS (eller disk), men om du installerar ditt eget operativsystem eller glömmer att aktivera den önskade tjänsten inuti VPS, vissa av data kan fortfarande gå förlorade. Utöver knappen erbjuds vanligtvis en datalagringstjänst, oftast mycket begränsad. Vanligtvis är detta ett konto med åtkomst via FTP eller SFTP, ibland tillsammans med SSH, med ett avskalat skal (till exempel rbash), eller en begränsning av att köra kommandon genom authorized_keys (via ForcedCommand).
En dedikerad server är ansluten till nätverket med två portar med en hastighet på 1 Gbps, ibland kan dessa vara kort med en hastighet på 10 Gbps. VPS har oftast ett nätverksgränssnitt. Oftast begränsar inte datacenter nätverkshastigheten inom datacentret, men de begränsar hastigheten för internetåtkomst.
Den typiska belastningen för en sådan dedikerad server eller VPS är en webbserver, en databas och en applikationsserver. Ibland kan olika tilläggstjänster installeras, inklusive för en webbserver eller databas: sökmotor, e-postsystem, etc.
En speciellt förberedd server fungerar som ett utrymme för att lagra säkerhetskopior, vi kommer att skriva om det mer i detalj senare.
Logisk organisation av disksystemet
Om du har en RAID-kontroller eller en VPS med en disk, och det inte finns några speciella preferenser för driften av diskundersystemet (till exempel en separat snabbdisk för databasen), är allt ledigt utrymme uppdelat enligt följande: en partition skapas och en LVM-volymgrupp skapas ovanpå den skapas flera volymer i den: 2 små av samma storlek, används som rotfilsystemet (ändrade en efter en under uppdateringar för möjlighet till snabb återställning, idén hämtades från Calculate Linux-distributionen), en annan är för swap-partitionen, resten av det lediga utrymmet är uppdelat i små volymer, som används som rotfilsystem för fullfjädrade behållare, diskar för virtuella maskiner, fil system för konton i /home (varje konto har sitt eget filsystem), filsystem för applikationsbehållare.
Viktig anmärkning: volymer måste vara helt fristående, d.v.s. bör inte bero på varandra eller på rotfilsystemet. I fallet med virtuella maskiner eller behållare observeras denna punkt automatiskt. Om dessa är applikationsbehållare eller hemkataloger bör du tänka på att separera konfigurationsfilerna för webbservern och andra tjänster på ett sådant sätt att beroenden mellan volymerna elimineras så mycket som möjligt. Till exempel, varje webbplats körs från sin egen användare, webbplatsens konfigurationsfiler finns i användarens hemkatalog, i webbserverns inställningar, webbplatsens konfigurationsfiler ingår inte via /etc/nginx/conf.d/.conf och till exempel /home//configs/nginx/*.conf
Om det finns flera diskar kan du skapa en mjukvaru-RAID-array (och konfigurera dess cachning på en SSD, om det finns ett behov och möjlighet), på vilken du kan bygga LVM enligt reglerna som föreslagits ovan. Även i det här fallet kan du använda ZFS eller BtrFS, men du bör tänka två gånger på detta: båda kräver en mycket mer seriös inställning till resurser, och dessutom ingår inte ZFS i Linux-kärnan.
Oavsett vilket schema som används är det alltid värt att i förväg uppskatta den ungefärliga hastigheten för att skriva ändringar till diskar och sedan beräkna mängden ledigt utrymme som kommer att reserveras för att skapa ögonblicksbilder. Till exempel, om vår server skriver data med en hastighet av 10 megabyte per sekund och storleken på hela datamatrisen är 10 terabyte - kan synkroniseringstiden nå en dag (22 timmar - det här är hur mycket en sådan volym kommer att överföras över nätverket 1 Gbps) - det är värt att reservera cirka 800 GB . I verkligheten kommer siffran att vara mindre, du kan säkert dividera den med antalet logiska volymer.
Backuplagringsserverenhet
Den största skillnaden mellan en server för att lagra säkerhetskopior är dess stora, billiga och relativt långsamma diskar. Eftersom moderna hårddiskar redan har passerat 10TB-ribban på en disk, är det nödvändigt att använda filsystem eller RAID med kontrollsummor, eftersom under återuppbyggnaden av arrayen eller återställningen av filsystemet (flera dagar!) kan den andra disken misslyckas på grund av till ökad belastning. På diskar med en kapacitet på upp till 1TB var detta inte så känsligt. För enkelhetens skull antar jag att diskutrymmet är uppdelat i två delar av ungefär lika stor storlek (återigen, till exempel med LVM):
- volymer som motsvarar servrarna som används för att lagra användardata (den senast gjorda säkerhetskopian kommer att distribueras på dem för verifiering);
- volymer som används som BorgBackup-förråd (data för säkerhetskopiering kommer att gå direkt hit).
Funktionsprincipen är att separata volymer skapas för varje server för BorgBackup repositories, dit data från stridsservrarna kommer att gå. Lagren fungerar i endast tilläggsläge, vilket eliminerar möjligheten att avsiktligt radera data, och på grund av deduplicering och periodisk rensning av förråd från gamla säkerhetskopior (årliga kopior kvarstår, månadsvis för det senaste året, veckovis för sista månaden, dagligen för förra veckan, eventuellt i speciella fall - varje timme för sista dagen: totalt 24 + 7 + 4 + 12 + årliga - cirka 50 exemplar för varje server).
BorgBackup-förråd aktiverar inte bara tilläggsläge, istället används en ForcedCommand i .ssh/authorized_keys ungefär så här:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......Den angivna sökvägen innehåller ett omslagsskript ovanpå borg, som, förutom att starta binären med parametrar, dessutom startar processen med att återställa säkerhetskopian efter att data har tagits bort. För att göra detta skapar wrapper-skriptet en taggfil bredvid motsvarande arkiv. Den senaste säkerhetskopian som gjordes återställs automatiskt till motsvarande logiska volym efter att datafyllningsprocessen är klar.
Den här designen gör att du med jämna mellanrum kan rensa upp onödiga säkerhetskopior och förhindrar även stridsservrar från att radera något på backuplagringsservern.
Säkerhetskopieringsprocess
Initiativtagaren till säkerhetskopieringen är den dedikerade servern eller VPS själv, eftersom detta schema ger mer kontroll över säkerhetskopieringsprocessen från denna servers sida. Först tas en ögonblicksbild av tillståndet för det aktiva rotfilsystemet, som monteras och laddas upp med BorgBackup till backuplagringsservern. När datainsamlingen är klar avmonteras och raderas ögonblicksbilden.
Om det finns en liten databas (upp till 1 GB för varje plats) görs en databasdump, som sparas i lämplig logisk volym, där resten av data för samma plats finns, men så att dumpen är inte tillgänglig via webbservern. Om databaserna är stora bör du konfigurera "het" databorttagning, till exempel med hjälp av xtrabackup för MySQL, eller arbeta med WAL med archive_command i PostgreSQL. I det här fallet kommer databasen att återställas separat från webbplatsdata.
Om behållare eller virtuella maskiner används bör du konfigurera qemu-guest-agent, CRIU eller annan nödvändig teknik. I andra fall behövs oftast inga ytterligare inställningar - vi skapar helt enkelt ögonblicksbilder av logiska volymer, som sedan bearbetas på samma sätt som en ögonblicksbild av rotfilsystemets tillstånd. När data har tagits raderas bilderna.
Ytterligare arbete utförs på backuplagringsservern:
- den senaste säkerhetskopian som gjordes i varje arkiv kontrolleras,
- förekomsten av en markeringsfil kontrolleras, vilket indikerar att datainsamlingsprocessen är klar,
- data utökas till motsvarande lokala volym,
- taggfilen raderas
Serveråterställningsprocess
Om huvudservern dör, startas en liknande dedikerad server, som startar från någon standardbild. Med största sannolikhet kommer nedladdningen att ske över nätverket, men datacenterteknikern som ställer in servern kan omedelbart kopiera denna standardbild till en av diskarna. Nedladdningen sker till RAM, varefter återställningsprocessen startar:
- en begäran görs att koppla en blockenhet via iscsinbd eller annat liknande protokoll till en logisk volym som innehåller rotfilsystemet för den avlidna servern; Eftersom rotfilsystemet måste vara litet bör detta steg slutföras på några minuter. Bootloadern är också återställd;
- strukturen för lokala logiska volymer återskapas, logiska volymer ansluts från backupservern med hjälp av kärnmodulen dm_clone: dataåterställning börjar och ändringar skrivs omedelbart till lokala diskar
- en behållare lanseras med alla tillgängliga fysiska diskar - serverns funktionalitet är helt återställd, men med reducerad prestanda;
- efter att datasynkroniseringen är klar kopplas de logiska volymerna från backupservern bort, behållaren stängs av och servern startas om;
Efter en omstart kommer servern att ha all data som fanns där när säkerhetskopian skapades, och kommer även att inkludera alla ändringar som gjordes under återställningsprocessen.
Andra artiklar i serien
Backup Del 7: Slutsatser
Jag inbjuder dig att diskutera det föreslagna alternativet i kommentarerna, tack för din uppmärksamhet!
Källa: will.com