Dette notatet fullfører syklusen om sikkerhetskopiering. Den vil diskutere den logiske organiseringen av en dedikert server (eller VPS), praktisk for sikkerhetskopiering, og vil også tilby et alternativ for raskt å gjenopprette en server fra en sikkerhetskopi uten mye nedetid i tilfelle en katastrofe.
Innledende data
En dedikert server har oftest minst to harddisker som tjener til å organisere en første-nivå RAID-array (speil). Dette er nødvendig for å kunne fortsette å betjene serveren hvis en disk svikter. Dersom dette er en vanlig dedikert server kan det være en egen hardware RAID-kontroller med aktiv caching-teknologi på SSD, slik at det i tillegg til vanlige harddisker kan kobles til en eller flere SSD-er. Noen ganger tilbys dedikerte servere, der de lokale diskene bare inneholder SATADOM (små disker, strukturelt sett en flash-stasjon koblet til en SATA-port), eller til og med en vanlig liten (8-16 GB) flash-stasjon koblet til en spesiell intern port, og data hentes fra lagringssystemet, koblet til via et dedikert lagringsnettverk (Ethernet 10G, FC, etc.), og det er dedikerte servere som lastes direkte fra lagringssystemet. Jeg vil ikke vurdere slike alternativer, siden i slike tilfeller går oppgaven med å sikkerhetskopiere serveren jevnt over til spesialisten som vedlikeholder lagringssystemet; vanligvis er det forskjellige proprietære teknologier for å lage øyeblikksbilder, innebygd deduplisering og andre gleder for systemadministratoren , diskutert i de forrige delene av denne serien. Volumet til en dedikert servers diskarray kan nå flere titalls terabyte, avhengig av antall og størrelse på disker som er koblet til serveren. Når det gjelder VPS, er volumene mer beskjedne: vanligvis ikke mer enn 100 GB (men det er også flere), og tariffene for slike VPS kan lett bli dyrere enn de billigste dedikerte serverne fra samme hoster. En VPS har oftest én disk, fordi det vil være et lagringssystem (eller noe hyperkonvergert) under den. Noen ganger har en VPS flere disker med forskjellige egenskaper, for forskjellige formål:
- lite system - for å installere operativsystemet;
- stor - lagring av brukerdata.
Når du installerer systemet på nytt ved hjelp av kontrollpanelet, overskrives ikke disken med brukerdata, men systemdisken fylles helt opp. I tilfelle av en VPS, kan hosteren tilby en knapp som tar et øyeblikksbilde av tilstanden til VPS (eller disk), men hvis du installerer ditt eget operativsystem eller glemmer å aktivere den ønskede tjenesten inne i VPS, noen av dataene kan fortsatt gå tapt. I tillegg til knappen tilbys vanligvis en datalagringstjeneste, som oftest svært begrenset. Vanligvis er dette en konto med tilgang via FTP eller SFTP, noen ganger sammen med SSH, med et nedstrippet skall (for eksempel rbash), eller en begrensning på å kjøre kommandoer gjennom authorized_keys (via ForcedCommand).
En dedikert server er koblet til nettverket med to porter med en hastighet på 1 Gbps, noen ganger kan dette være kort med en hastighet på 10 Gbps. VPS har oftest ett nettverksgrensesnitt. Oftest begrenser ikke datasentre nettverkshastigheten i datasenteret, men de begrenser hastigheten på Internett-tilgang.
Den typiske belastningen til en slik dedikert server eller VPS er en webserver, en database og en applikasjonsserver. Noen ganger kan ulike tilleggstjenester installeres, inkludert for en webserver eller database: søkemotor, e-postsystem, etc.
En spesielt forberedt server fungerer som et rom for lagring av sikkerhetskopier; vi vil skrive om det mer detaljert senere.
Logisk organisering av disksystemet
Hvis du har en RAID-kontroller, eller en VPS med én disk, og det ikke er noen spesielle preferanser for driften av diskundersystemet (for eksempel en egen hurtigdisk for databasen), er all ledig plass delt som følger: én partisjon opprettes, og en LVM-volumgruppe opprettes på toppen av den, opprettes flere volumer i den: 2 små av samme størrelse, brukt som rotfilsystemet (endret en etter en under oppdateringer for mulighet for rask tilbakerulling, ideen ble plukket opp fra Calculate Linux-distribusjonen), en annen er for swap-partisjonen, resten av den ledige plassen er delt inn i små volumer, brukt som rotfilsystem for fullverdige containere, disker for virtuelle maskiner, fil systemer for kontoer i /home (hver konto har sitt eget filsystem), filsystemer for applikasjonsbeholdere.
Viktig merknad: volumer må være fullstendig selvstendige, dvs. bør ikke avhenge av hverandre eller av rotfilsystemet. Når det gjelder virtuelle maskiner eller containere, observeres dette punktet automatisk. Hvis dette er applikasjonsbeholdere eller hjemmekataloger, bør du tenke på å skille konfigurasjonsfilene til webserveren og andre tjenester på en slik måte at du eliminerer avhengigheter mellom volumene så mye som mulig. For eksempel kjører hvert nettsted fra sin egen bruker, nettstedskonfigurasjonsfilene er i brukerens hjemmekatalog, i nettserverinnstillingene er nettstedkonfigurasjonsfiler ikke inkludert via /etc/nginx/conf.d/.conf, og for eksempel /home//configs/nginx/*.conf
Hvis det er flere disker, kan du opprette en programvare-RAID-array (og konfigurere dens caching på en SSD, hvis det er behov og mulighet), på toppen av dette kan du bygge LVM i henhold til reglene foreslått ovenfor. Også i dette tilfellet kan du bruke ZFS eller BtrFS, men du bør tenke to ganger på dette: begge krever en mye mer seriøs tilnærming til ressurser, og dessuten er ZFS ikke inkludert i Linux-kjernen.
Uavhengig av skjemaet som brukes, er det alltid verdt å estimere på forhånd den omtrentlige hastigheten for å skrive endringer til disker, og deretter beregne mengden ledig plass som vil bli reservert for å lage øyeblikksbilder. For eksempel, hvis serveren vår skriver data med en hastighet på 10 megabyte per sekund, og størrelsen på hele datamatrisen er 10 terabyte - kan synkroniseringstiden nå en dag (22 timer - dette er hvor mye et slikt volum vil bli overført over nettverket 1 Gbps) - det er verdt å reservere ca 800 GB . I virkeligheten vil tallet være mindre; du kan trygt dele det med antall logiske volumer.
Sikkerhetskopier lagringsserverenhet
Hovedforskjellen mellom en server for lagring av sikkerhetskopier er dens store, billige og relativt trege disker. Siden moderne HDD-er allerede har krysset 10TB-linjen på en disk, er det nødvendig å bruke filsystemer eller RAID med kontrollsummer, fordi under gjenoppbyggingen av matrisen eller gjenopprettingen av filsystemet (flere dager!) kan den andre disken svikte pga. til økt belastning. På disker med en kapasitet på opptil 1TB var ikke dette så følsomt. For enkelhets skyld antar jeg at diskplassen er delt inn i to deler av omtrent samme størrelse (igjen, for eksempel ved å bruke LVM):
- volumer som tilsvarer serverne som brukes til å lagre brukerdata (den siste sikkerhetskopien som ble laget vil bli distribuert på dem for verifisering);
- volumer brukt som BorgBackup-depoter (data for sikkerhetskopiering vil gå direkte hit).
Driftsprinsippet er at det lages separate volumer for hver server for BorgBackup-repositoriene, hvor data fra kampserverne skal gå. Lagrene opererer i bare vedleggsmodus, som eliminerer muligheten for bevisst sletting av data, og på grunn av deduplisering og periodisk rengjøring av lagre fra gamle sikkerhetskopier (årlige kopier gjenstår, månedlig for det siste året, ukentlig for siste måned, daglig for forrige uke, eventuelt i spesielle tilfeller - hver time for siste dag: totalt 24 + 7 + 4 + 12 + årlig - ca. 50 eksemplarer for hver server).
BorgBackup-lagre aktiverer ikke bare vedleggsmodus, i stedet brukes en ForcedCommand i .ssh/authorized_keys omtrent slik:
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 angitte banen inneholder et wrapper-skript på toppen av borg, som, i tillegg til å starte binæren med parametere, i tillegg starter prosessen med å gjenopprette sikkerhetskopien etter at dataene er fjernet. For å gjøre dette oppretter wrapper-skriptet en tag-fil ved siden av det tilsvarende depotet. Den siste sikkerhetskopieringen gjenopprettes automatisk til det tilsvarende logiske volumet etter at datafyllingsprosessen er fullført.
Denne utformingen lar deg med jevne mellomrom rydde opp i unødvendige sikkerhetskopier, og forhindrer også kampservere i å slette noe på backuplagringsserveren.
Sikkerhetskopieringsprosess
Initiativtakeren til sikkerhetskopieringen er den dedikerte serveren eller VPS selv, siden denne ordningen gir mer kontroll over sikkerhetskopieringsprosessen fra denne serverens side. Først tas et øyeblikksbilde av tilstanden til det aktive rotfilsystemet, som monteres og lastes opp ved hjelp av BorgBackup til backuplagringsserveren. Etter at datafangst er fullført, demonteres og slettes øyeblikksbildet.
Hvis det er en liten database (opptil 1 GB for hvert sted), lages det en databasedump, som lagres i passende logisk volum, hvor resten av dataene for samme sted er plassert, men slik at dumpen er ikke tilgjengelig via webserveren. Hvis databasene er store, bør du konfigurere "hot" datafjerning, for eksempel ved å bruke xtrabackup for MySQL, eller jobbe med WAL med archive_command i PostgreSQL. I dette tilfellet vil databasen gjenopprettes separat fra nettstedsdataene.
Hvis containere eller virtuelle maskiner brukes, bør du konfigurere qemu-guest-agent, CRIU eller andre nødvendige teknologier. I andre tilfeller er det oftest ikke nødvendig med tilleggsinnstillinger - vi lager ganske enkelt øyeblikksbilder av logiske volumer, som deretter behandles på samme måte som et øyeblikksbilde av tilstanden til rotfilsystemet. Etter at dataene er tatt, slettes bildene.
Videre arbeid utføres på backuplagringsserveren:
- den siste sikkerhetskopien som er laget i hvert depot, kontrolleres,
- tilstedeværelsen av en merkefil kontrolleres, noe som indikerer at datainnsamlingsprosessen er fullført,
- dataene utvides til det tilsvarende lokale volumet,
- merkefilen slettes
Servergjenopprettingsprosess
Hvis hovedserveren dør, startes en lignende dedikert server, som starter opp fra et standardbilde. Mest sannsynlig vil nedlastingen foregå over nettverket, men datasenterteknikeren som setter opp serveren kan umiddelbart kopiere dette standardbildet til en av diskene. Nedlastingen skjer til RAM, hvoretter gjenopprettingsprosessen starter:
- det gjøres en forespørsel om å koble en blokkenhet via iscsinbd eller en annen lignende protokoll til et logisk volum som inneholder rotfilsystemet til den avdøde serveren; Siden rotfilsystemet må være lite, bør dette trinnet fullføres på noen få minutter. Oppstartslasteren er også gjenopprettet;
- strukturen til lokale logiske volumer gjenskapes, logiske volumer kobles til fra backupserveren ved å bruke dm_clone-kjernemodulen: datagjenoppretting begynner, og endringer skrives umiddelbart til lokale disker
- en beholder lanseres med alle tilgjengelige fysiske disker - serverens funksjonalitet er fullstendig gjenopprettet, men med redusert ytelse;
- etter at datasynkroniseringen er fullført, kobles de logiske volumene fra backupserveren fra, beholderen slås av og serveren startes på nytt;
Etter en omstart vil serveren ha alle dataene som var der da sikkerhetskopien ble opprettet, og vil også inkludere alle endringene som ble gjort under gjenopprettingsprosessen.
Andre artikler i serien
Backup Del 7: Konklusjoner
Jeg inviterer deg til å diskutere det foreslåtte alternativet i kommentarene, takk for oppmerksomheten!
Kilde: www.habr.com