Denne note fuldender cyklussen om sikkerhedskopiering. Det vil diskutere den logiske organisering af en dedikeret server (eller VPS), praktisk til backup, og vil også tilbyde en mulighed for hurtigt at gendanne en server fra en backup uden meget nedetid i tilfælde af en katastrofe.
Indledende data
En dedikeret server har oftest mindst to harddiske, der tjener til at organisere et RAID-array (spejl) på første niveau. Dette er nødvendigt for at kunne fortsætte driften af serveren, hvis en disk fejler. Hvis der er tale om en almindelig dedikeret server, kan der være en separat hardware RAID controller med aktiv caching teknologi på SSD, så der udover almindelige harddiske kan tilsluttes en eller flere SSD. Nogle gange tilbydes dedikerede servere, hvor de eneste lokale diske er SATADOM (små diske, strukturelt set et flashdrev tilsluttet en SATA-port), eller endda et almindeligt lille (8-16GB) flashdrev tilsluttet en speciel intern port, og data tages fra lagersystemet, forbundet via et dedikeret lagernetværk (Ethernet 10G, FC osv.), og der er dedikerede servere, der indlæses direkte fra lagersystemet. Jeg vil ikke overveje sådanne muligheder, da opgaven med at sikkerhedskopiere serveren glat overgår til specialisten, der vedligeholder lagersystemet; normalt er der forskellige proprietære teknologier til at skabe snapshots, indbygget deduplikering og andre glæder for systemadministratoren , diskuteret i de foregående dele af denne serie. Volumen af en dedikeret servers diskarray kan nå op på flere snese terabyte, afhængigt af antallet og størrelsen af diske, der er tilsluttet serveren. I tilfældet med VPS er mængderne mere beskedne: normalt ikke mere end 100 GB (men der er også flere), og taksterne for en sådan VPS kan sagtens være dyrere end de billigste dedikerede servere fra samme hoster. En VPS har oftest én disk, fordi der vil være et lagersystem (eller noget hyperkonvergeret) under den. Nogle gange har en VPS flere diske med forskellige karakteristika til forskellige formål:
- lille system - til installation af operativsystemet;
- stor - lagring af brugerdata.
Når du geninstallerer systemet ved hjælp af kontrolpanelet, overskrives disken med brugerdata ikke, men systemdisken er fuldstændig genopfyldt. I tilfælde af en VPS kan hosteren også tilbyde en knap, der tager et øjebliksbillede af VPS'ens (eller diskens) tilstand, men hvis du installerer dit eget operativsystem eller glemmer at aktivere den ønskede tjeneste inde i VPS'en, vil nogle af dataene kan stadig gå tabt. Ud over knappen tilbydes normalt en datalagringstjeneste, oftest meget begrænset. Typisk er dette en konto med adgang via FTP eller SFTP, nogle gange sammen med SSH, med en strippet skal (f.eks. rbash) eller en begrænsning i at køre kommandoer gennem authorized_keys (via ForcedCommand).
En dedikeret server er forbundet til netværket med to porte med en hastighed på 1 Gbps, nogle gange kan disse være kort med en hastighed på 10 Gbps. VPS har oftest én netværksgrænseflade. Oftest begrænser datacentre ikke netværkshastigheden i datacentret, men begrænser hastigheden på internetadgang.
Den typiske belastning af en sådan dedikeret server eller VPS er en webserver, en database og en applikationsserver. Nogle gange kan forskellige ekstra hjælpetjenester installeres, herunder til en webserver eller database: søgemaskine, mailsystem osv.
En specielt forberedt server fungerer som et rum til opbevaring af sikkerhedskopier; vi vil skrive om det mere detaljeret senere.
Logisk organisering af disksystemet
Hvis du har en RAID-controller eller en VPS med én disk, og der ikke er særlige præferencer for driften af diskundersystemet (for eksempel en separat hurtigdisk til databasen), er al ledig plads opdelt som følger: én partition oprettes, og der oprettes en LVM-volumengruppe oven på den, oprettes flere bind i den: 2 små af samme størrelse, brugt som rodfilsystemet (ændret en efter en under opdateringer for mulighed for hurtig tilbagerulning, idéen blev hentet fra Calculate Linux-distributionen), en anden er til swap-partitionen, resten af den ledige plads er opdelt i små mængder, der bruges som rodfilsystem til fuldgyldige containere, diske til virtuelle maskiner, fil systemer til konti i /home (hver konto har sit eget filsystem), filsystemer til applikationscontainere.
Vigtig bemærkning: bind skal være fuldstændig selvstændige, dvs. bør ikke afhænge af hinanden eller af rodfilsystemet. I tilfælde af virtuelle maskiner eller containere observeres dette punkt automatisk. Hvis disse er applikationscontainere eller hjemmemapper, bør du overveje at adskille konfigurationsfilerne for webserveren og andre tjenester på en sådan måde, at afhængigheder mellem volumerne så meget som muligt elimineres. For eksempel kører hvert websted fra sin egen bruger, webstedets konfigurationsfiler er i brugerens hjemmemappe, i webserverindstillingerne er webstedskonfigurationsfiler ikke inkluderet via /etc/nginx/conf.d/.conf, og for eksempel /home//configs/nginx/*.conf
Hvis der er flere diske, kan du oprette et software-RAID-array (og konfigurere dets caching på en SSD, hvis der er behov og mulighed), oven på hvilket du kan bygge LVM i henhold til reglerne foreslået ovenfor. Også i dette tilfælde kan du bruge ZFS eller BtrFS, men du bør tænke dig om to gange: begge kræver en meget mere seriøs tilgang til ressourcer, og desuden er ZFS ikke inkluderet i Linux-kernen.
Uanset hvilket skema der bruges, er det altid værd at estimere på forhånd den omtrentlige hastighed for at skrive ændringer til diske og derefter beregne mængden af ledig plads, der vil blive reserveret til at oprette snapshots. For eksempel, hvis vores server skriver data med en hastighed på 10 megabyte pr. sekund, og størrelsen af hele dataarrayet er 10 terabyte - kan synkroniseringstiden nå op på en dag (22 timer - det er hvor meget sådan en volumen vil blive overført over netværket 1 Gbps) - det er værd at reservere omkring 800 GB . I virkeligheden vil tallet være mindre; du kan roligt dividere det med antallet af logiske bind.
Backup lagerserverenhed
Den største forskel mellem en server til lagring af sikkerhedskopier er dens store, billige og relativt langsomme diske. Da moderne HDD'er allerede har krydset 10TB-baren på én disk, er det nødvendigt at bruge filsystemer eller RAID med kontrolsummer, fordi under genopbygningen af arrayet eller gendannelsen af filsystemet (flere dage!) kan den anden disk fejle pga. til øget belastning. På diske med en kapacitet på op til 1 TB var dette ikke så følsomt. For nemheds skyld antager jeg, at diskpladsen er opdelt i to dele af omtrent samme størrelse (igen, for eksempel ved hjælp af LVM):
- mængder svarende til de servere, der bruges til at gemme brugerdata (den sidst lavede backup vil blive installeret på dem til verifikation);
- mængder, der bruges som BorgBackup-lagre (data til sikkerhedskopier vil gå direkte her).
Funktionsprincippet er, at der oprettes separate volumener for hver server til BorgBackup-lagrene, hvor data fra kampserverne vil gå. Lagrene fungerer i kun tilføjelsestilstand, hvilket eliminerer muligheden for bevidst sletning af data, og på grund af deduplikering og periodisk rensning af lagre fra gamle sikkerhedskopier (årlige kopier forbliver, månedligt for det sidste år, ugentligt for den sidste måned, dagligt for sidste uge, eventuelt i særlige tilfælde - hver time for sidste dag: i alt 24 + 7 + 4 + 12 + årlige - ca. 50 eksemplarer for hver server).
BorgBackup-lagre aktiverer ikke kun tilføjelsestilstand, i stedet bruges en ForcedCommand i .ssh/authorized_keys noget som dette:
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 angivne sti indeholder et wrapper-script oven på borg, som udover at starte det binære med parametre, desuden starter processen med at gendanne sikkerhedskopien, efter at dataene er fjernet. For at gøre dette opretter wrapper-scriptet en tag-fil ved siden af det tilsvarende lager. Den sidste sikkerhedskopiering gendannes automatisk til den tilsvarende logiske volumen, efter at dataudfyldningsprocessen er afsluttet.
Dette design giver dig mulighed for med jævne mellemrum at rydde op i unødvendige sikkerhedskopier og forhindrer også kampservere i at slette noget på backup-lagerserveren.
Backup proces
Initiativtageren til backup er den dedikerede server eller VPS selv, da denne ordning giver mere kontrol over backup-processen fra denne servers side. Først tages et øjebliksbillede af det aktive rodfilsystems tilstand, som monteres og uploades ved hjælp af BorgBackup til backup-lagerserveren. Når datafangsten er fuldført, afmonteres snapshotet og slettes.
Hvis der er en lille database (op til 1 GB for hvert sted), laves et databasedump, som gemmes i den passende logiske volumen, hvor resten af dataene for samme sted er placeret, men således at dumpet er ikke tilgængelig via webserveren. Hvis databaserne er store, bør du konfigurere "hot" datafjernelse, for eksempel ved hjælp af xtrabackup til MySQL, eller arbejde med WAL med archive_command i PostgreSQL. I dette tilfælde vil databasen blive gendannet separat fra webstedets data.
Hvis der bruges containere eller virtuelle maskiner, skal du konfigurere qemu-guest-agent, CRIU eller andre nødvendige teknologier. I andre tilfælde er yderligere indstillinger oftest ikke nødvendige - vi laver blot snapshots af logiske volumener, som derefter behandles på samme måde som et snapshot af tilstanden af rodfilsystemet. Når dataene er taget, slettes billederne.
Yderligere arbejde udføres på backup-lagerserveren:
- den sidste sikkerhedskopi, der er lavet i hvert lager, kontrolleres,
- tilstedeværelsen af en mærkefil kontrolleres, hvilket indikerer, at dataindsamlingsprocessen er afsluttet,
- dataene udvides til den tilsvarende lokale mængde,
- tag-filen slettes
Servergendannelsesproces
Hvis hovedserveren dør, lanceres en lignende dedikeret server, som starter fra et standardbillede. Mest sandsynligt vil overførslen finde sted over netværket, men datacenterteknikeren, der opsætter serveren, kan straks kopiere dette standardbillede til en af diskene. Downloaden sker i RAM, hvorefter gendannelsesprocessen starter:
- der foretages en anmodning om at vedhæfte en blokenhed via iscsinbd eller en anden lignende protokol til en logisk volumen, der indeholder rodfilsystemet på den afdøde server; Da rodfilsystemet skal være lille, bør dette trin være afsluttet på få minutter. Bootloaderen er også gendannet;
- strukturen af lokale logiske volumener genskabes, logiske volumener tilknyttes fra backupserveren ved hjælp af dm_clone kernemodulet: datagendannelse begynder, og ændringer skrives straks til lokale diske
- en container lanceres med alle tilgængelige fysiske diske - serverens funktionalitet er fuldt gendannet, men med reduceret ydeevne;
- efter at datasynkronisering er fuldført, afbrydes de logiske volumener fra backupserveren, beholderen slukkes, og serveren genstartes;
Efter en genstart vil serveren have alle de data, der var der på det tidspunkt, hvor sikkerhedskopien blev oprettet, og vil også inkludere alle de ændringer, der blev foretaget under gendannelsesprocessen.
Andre artikler i serien
Backup Del 7: Konklusioner
Jeg inviterer dig til at diskutere den foreslåede mulighed i kommentarerne, tak for din opmærksomhed!
Kilde: www.habr.com