Denne note afslutter cyklussen om backup. Den vil omhandle den logiske organisering af en dedikeret server (eller VPS), der er praktisk til backup, og der vil blive foreslået en metode til hurtig gendannelse af serveren fra en sikkerhedskopi uden større nedetid i tilfælde af nedbrud.
Kildedata
En dedikeret server har ofte mindst to harddiske, der bruges til at organisere et RAID-niveau 1-array (spejling). Dette er nødvendigt for at kunne fortsætte driften af serveren, hvis en disk fejler. Hvis det er en almindelig dedikeret server, kan der være en separat hardware RAID-controller med aktiv cache-teknologi på SSD, så der udover de almindelige harddiske kan tilsluttes en eller flere SSD'er. Nogle gange tilbydes dedikerede servere, hvor der kun findes SATADOM-diske (små diske, der konstruktionelt er – en flash-enhed tilsluttet en SATA-port), eller endda en almindelig lille (8-16 GB) USB-flash-enhed, der tilsluttes en speciel intern port, mens data hentes fra et SAN, der er tilsluttet via et dedikeret datalagringsnetværk (Ethernet 10G, FC osv.). Der findes også dedikerede servere, der boots direkte fra et SAN. Sådanne muligheder vil jeg ikke behandle, da opgaven med at sikkerhedskopiere serveren i sådanne tilfælde glider over til specialisten, der vedligeholder SAN'et, hvor der normalt findes forskellige proprietære teknologier til oprettelse af snapshots, indbygget deduplication og andre glæder for systemadministratorer, som er behandlet i de foregående dele af denne cyklus. Volumenet af det diskarray, der er tilsluttet den dedikerede server, kan nå op på flere titusinde terabyte, afhængigt af antallet og kapaciteten af de diske, der er tilsluttet serveren. I tilfælde af VPS er volumenerne mere beskedne: normalt ikke mere end 100 GB (men der findes også større), og priserne for sådanne VPS kan nemt være dyrere end de billigste dedikerede servere fra den samme hostingudbyder. VPS har oftest kun en disk, fordi der vil være et SAN (eller noget hyperkonvergent) under den. Nogle gange har VPS flere diske med forskellige specifikationer til forskellige formål:
- lille systemdisk — til installation af operativsystemet;
- stor disk — til opbevaring af brugerdata.
Ved geninstallation af systemet gennem kontrolpanelet slettes disken med brugerdata ikke, mens systemdisken gendannes fuldstændigt. I tilfælde af VPS kan udbyderen tilbyde en knap, der laver et snapshot af VPS'en (eller disken), men hvis du installerer dit eget operativsystem eller glemmer at aktivere den nødvendige service inden for VPS, kan dele af dataene stadig gå tabt. Sammen med knappen tilbydes der typisk en datalagringstjeneste, som oftest er stærkt begrænset. Det er normalt en konto med adgang via FTP eller SFTP-protokollen, nogle gange sammen med SSH, med en begrænset shell (f.eks. rbash) eller begrænsninger på kommandoer gennem authorized_keys (via ForcedCommand).
Den dedikerede server er tilsluttet netværket via to porte med en hastighed på 1 Gbit/s, nogle gange kan det være kort med en hastighed på 10 Gbit/s. VPS har som regel kun én netværksinterface. Datacentre begrænser som regel ikke netværkshastigheden inden for datacentret, men de begrænser hastigheden for internetadgang.
Den typiske belastning for en sådan dedikeret server eller VPS består af en webserver, en database og en applikationsserver. Nogle gange kan der installeres forskellige yderligere støttetjenester, herunder for webserveren eller databasen: søgemaskiner, mailsystemer osv.
Som lagerplads til backup fungerer en specielt forberedt server, som der vil blive skrevet mere om senere.
Logisk organisation af filsystemet
Hvis der er en RAID-controller, eller dette er et VPS med én disk, og der ikke er særlige præferencer for, hvordan diskundersystemet skal arbejde (for eksempel en separat hurtig disk til databasen) — deles det frie rum således: der oprettes en partition, ovenpå denne oprettes en LVM-volumengrupp, hvor der oprettes flere volumer: 2 små af samme størrelse, der bruges som roddisk (de skiftes ud efter hinanden ved opdateringer for at muliggøre hurtig rollback, idéen er taget fra distributionen Calculate Linux), en anden — til swap-partitionen, det resterende frie rum deles op i små volumer, der bruges som roddisk til fuldgyldige containere, diske til virtuelle maskiner, filsystemer til brugerkonti i /home (hver konto har sit eget filsystem), filsystemer til applikationscontainere.
Vigtig bemærkning: volumenerne skal være fuldstændig selvforsynende, dvs. de må ikke være afhængige af hinanden eller af roddiskene. I tilfælde af virtuelle maskiner eller containere overholdes dette punkt automatisk. Men hvis det drejer sig om applikationscontainere eller hjemmekataloger — er det værd at overveje at adskille konfigurationsfilerne for webserveren og andre tjenester på en måde, der maksimerer elimineringen af afhængigheder mellem volumenerne. For eksempel kører hver hjemmeside som sin egen bruger, konfigurationsfilerne for websitet findes i brugerens hjemmekatalog, og i webserverens indstillinger inkluderes konfigurationsfiler til websites ikke via /etc/nginx/conf.d/.conf, men for eksempel /home//configs/nginx/*.conf
Hvis der derimod er flere diske — kan der oprettes et software RAID-array (og konfigureres caching til SSD, hvis der er behov og muligheder), ovenpå hvilket der kan samles LVM efter reglerne foreslået tidligere. I dette tilfælde kan ZFS eller BtrFS også bruges, men her skal man tænke flere gange: begge kræver en meget mere seriøs tilgang til ressourcer, og ZFS medfølger desuden ikke med Linux-kernen.
Uanset hvilken skema der anvendes, er det altid en god idé at vurdere den omtrentlige skrivehastighed for ændringer til diskene, hvorefter størrelsen af den ledige plads, der vil blive reserveret til oprettelse af snapshots, kan beregnes. For eksempel, hvis vores server skriver data med en hastighed på 10 megabyte per sekund, og den samlede datamængde er 10 terabyte — kan synkroniseringstiden nå op på et døgn (22 timer — det vil tage så lang tid at overføre denne mængde over et 1 Gbit/s netværk) — er det fornuftigt at reservere omkring 800 GB. I virkeligheden vil tallet være lavere, man kan trygt dele det med antallet af logiske partitioner.
Backup-lagringsserver
Den vigtigste forskel ved en server til backuplagring er store, billige og relativt langsomme diske. Da moderne HDD'er allerede er steget over 10 TB i en enkelt disk — er det nødvendigt at anvende filsystemer eller RAID med kontrolsummer, fordi under ombygningen af arrayet eller gendannelsen af filsystemet (flere dage!) kan den anden disk fejle på grund af den øgede belastning. På diske med en kapacitet op til 1 TB var det ikke så følsomt. For enkelhedens skyld antager jeg, at diskpladsen er opdelt i to omtrent lige store dele (igen, for eksempel ved hjælp af LVM):
- partitioner, der svarer til de servere, der anvendes til opbevaring af brugerdata (her vil den seneste oprettede backup blive gendannet til kontrol);
- partitioner, der bruges som BorgBackup-repositorier (her vil data til backup direkte blive gemt).
Princippet i arbejdet er, at der oprettes separate partitioner for hver server til BorgBackup-repositorier, hvor data fra produktionsserverne vil blive sendt. Repositorierne fungerer i en kun-tilføjelsesstand, hvilket udelukker muligheden for bevidst sletning af data, og gennem deduplikering og periodisk oprydning af repositorierne fra gamle backups (årlige kopier forbliver, månedlige fra det seneste år, ugentlige fra den seneste måned, daglige fra den seneste uge, muligvis — i særlige tilfælde — hver time fra den seneste dag: i alt 24 + 7 + 4 + 12 + årlige — cirka 50 kopier for hver server).
I BorgBackup-repositorier aktiveres ikke tilstand kun tilføjelse; i stedet bruges ForcedCommand i .ssh/authorized_keys i denne retning:
from="serveradresse",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.......På den angivne sti ligger et wrapper-script oven på borg, som udover at starte binæren med parametre også starter en proces for at genskabe backupen efter afslutningen af dataudtagning. Til dette formål opretter wrapper-scriptet en flagfil ved siden af det tilsvarende repository. Den sidste udførte backup bliver automatisk genskabt på den relevante logiske volumen efter afslutningen af dataoverførslen.
Denne konstruktion muliggør periodisk oprydning af unødvendige backups og forhindrer også produktionsservere i at slette noget på backup-serveren.
Backup-processen
Initiativtageren til backup er selve den dedikerede server eller VPS, da denne ordning giver mere kontrol over backup-processen fra denne server. Først tages et snapshot af den aktive rodfilsystemtilstand, som monteres og uploades ved hjælp af BorgBackup til backup-serveren. Efter dataudtagningen bliver snapshot'et derefter afmonteret og slettet.
I tilfælde af en lille database (op til 1 GB for hver side) laves der en databasemump, som gemmes i den relevante logiske volumen, der hvor de øvrige data for den samme side ligger, men sådan at dumpen ikke er tilgængelig via webserveren. Hvis databaserne er store, skal der indstilles "hot" dataudtagning, f.eks. ved hjælp af xtrabackup til MySQL eller brug af WAL med archive_command i PostgreSQL. I så fald vil databasen blive genskabt separat fra hjemmeside-dataene.
Hvis der anvendes containere eller virtuelle maskiner, skal qemu-guest-agent, CRIU eller andre nødvendige teknologier konfigureres. I andre tilfælde er der oftest ikke behov for yderligere konfiguration — blot opretter vi snapshots af de logiske volumen, som derefter behandles som snapshot'et af rodfilsystemets tilstand. Efter dataudtagningen bliver snapshots slettet.
Det videre arbejde foregår på backup-serveren:
- Den seneste udførte sikkerhedskopi kontrolleres i hver depot.
- Tilstedeværelsen af en flagfil, der angiver, at dataoverførselsprocessen er afsluttet, kontrolleres.
- Data rulles tilbage på den relevante lokale volumen.
- Flagfilen slettes.
Processen for at genoprette serverens funktionalitet.
Hvis den primære server svigter, startes en lignende dedikeret server, som booter fra et standardbillede. Det er sandsynligt, at booting vil ske over netværket, men teknikerne i datacentret, der konfigurerer serveren, kan straks kopiere dette standardbillede til en af diskene. Bootningen sker i RAM, hvorefter genoprettelsesprocessen starter:
- Der sendes en anmodning om tilslutning af en blok-enhed via iscsinbd eller et andet lignende protokol til det logiske volumen, der indeholder den rodfilssystem, som den nedlagte server havde; da rodfilssystemet skal være lille, skal dette trin være afsluttet inden for få minutter. Derudover genoprettes bootloaderen;
- Strukturen af lokale logiske volumener genskabes, og logiske volumener fra sikkerhedskopieringsserveren tilsluttes ved hjælp af dm_clone-kernemodulet: dataene begynder at blive genskabt, og ændringerne skrives straks til de lokale diske.
- En container startes med alle tilgængelige fysiske diske — serverens funktionalitet genoprettes fuldt ud, men med nedsat ydeevne;
- Efter datasykronisering frigøres de logiske volumener fra sikkerhedskopieringsserveren, containeren slukkes, og serveren genstartes;
Efter genstart vil serveren have alle de data, der var på tidspunktet for oprettelsen af sikkerhedskopien samt inkludere alle ændringer, der blev foretaget under genoprettelsesprocessen.
Andre artikler i serien
Backup, del 7: Konklusioner
Jeg inviterer til at diskutere det foreslåede forslag i kommentarerne, tak for opmærksomheden!
Kilde: habr.com
