Krypterade säkerhetskopior som du faktiskt kan återställa.

Välj arkivgränsen

Använd ett separat mål och separata inloggningsuppgifter från produktionsservern. Kryptering på klientsidan kan skydda lagrade kopior, men förrådets lösenord eller nyckel måste säkerhetskopieras privat. Om den förloras kan varje krypterad ögonblicksbild bli oanvändbar.

Samla in konsekventa data

Använd databasinbyggda dumpar eller en programvarustödd ögonblicksbildsprocedur. Säkerhetskopiera konfiguration, driftsättningsinstruktioner och de skyddade hemligheter som krävs för återställning. Uteslut endast tillfälliga cachar när du vet att de kan byggas upp igen.

Gör radering svårare

Överväg ett mål som endast kan läggas till eller är oföränderligt, där källmaskinen inte kan radera varje historisk kopia. Håll autentiseringsuppgifter för kvarhållning och gallring åtskilda där det är möjligt. Kryptering ensam hindrar inte en komprometterad server från att radera ett skrivbart arkiv.

Schemalägg kontroller och återställningsövningar

Övervaka jobbets slutstatus och åldern på den senaste fungerande säkerhetskopian. Kör integritetskontroller av databasen som verktyget stöder. Återställ ett urval regelbundet och genomför en fullständig återställningsövning efter större applikationsändringar.

Skilj på att lägga till en kopia och att radera historik

Ett destination som bara tillåter tillägg kan låta produktionsservern lägga till ögonblicksbilder medan raderingsbehörigheten finns kvar på en separat betrodd maskin. Kvarhållning kräver fortfarande noggrann granskning: förfalskade nyare ögonblicksbilder kan undergräva vissa kalenderbaserade urvalsprinciper. Kontrollera verktygets vägledning, kör en torrkörning av kvarhållning och övervaka kapaciteten. Restics forget-åtgärd väljer ögonblicksbilder; pruning tar bort orefererad lagrad data.

• Håll underhållsuppgifter för repositoriet borta från produktionsmaskinen
• Kör en torrkörning av retention innan radering tillåts
• Använd ett nytt tomt mål för varje återställningsövning

restic check
restic snapshots
restic restore latest --target /srv/restore-drill

Officiell dokumentation: Restic-retention och rensning

En återställningsövning med ett godkänt villkor

Välj ett realistiskt fel: en raderad fil, en förlorad databas eller en fullständig ombyggnad av maskinen. Återställ till en separat katalog eller isolerad värd. Verifiera filinnehåll, behörigheter och programmets förmåga att använda dem. Anteckna förfluten tid och eventuella manuella steg som saknades i runbooken. En kontroll av arkivet bekräftar en annan egenskap än en fungerande programåterställning.

• Återställ inte över den aktiva applikationen som ett första test
• Bekräfta att krypteringsuppgifterna kan återställas oberoende
• Larma om den senaste lyckade säkerhetskopieringen överskrider ditt återställningsmål

Bygg ett återställningsmanifest innan du väljer undantag

Lista det som inte kan återskapas genom att installera om ett paket: databasinnehåll, uppladdningar, applikationskonfiguration, signerings- eller krypteringsnycklar och distributionsversioner. Anteckna konsistensmetoden bredvid varje post. En databasdump tillhör en bestämd tidpunkt; att kopiera en databaskatalog som används kan ge ett annat resultat. Förvara åtkomst till arkivet, dess lösenfras och eventuell Borg-nyckelexport på en separat privat återställningsplats. Testa att en ersättningsmaskin kan öppna arkivet innan du gör den till den enda återställningskopian.

• Ange återställningspunktmålet: hur mycket nyligen utfört arbete som får gå förlorat. Sätt schemat utifrån det kravet.
• Ange återställningstidsmålet: hur lång tid en återuppbyggnad får ta. Inkludera databasimport och DNS-ändringar i övningen.
• Kontrollera att ett undantag avsett för cachar inte också tar bort uppladdningar, containervolymer eller skyddad konfiguration.
• Använd dokumentationen för den installerade Borg-huvudversionen; förvarsformat och kommandon är inte utbytbara mellan alla versioner.

Officiell dokumentation: Borg: kryptering, konsekvens och återställning

Kontrollera lagrade data samt metadata för arkivet

Restics standardkontroll av förvaret och en genomläsningsverifiering utför olika arbete. Schemalägg dataverifiering med hänsyn till dess bandbredds- och körtidskostnad. Exemplet kontrollerar en definierad femtedel av packfilerna; efterföljande schemalagda kontroller måste använda de övriga fraktionerna för att täcka förvaret. Ett slumpmässigt valt delurval ger inte samma täckningsgaranti. Ingen av åtgärderna bevisar att applikationen kan starta med återställda data.

restic check --read-data-subset=1/5
restic snapshots --host example-host
restic restore latest --host example-host --target /srv/restore-drill

Officiell dokumentation: restic: kontroller av arkiv och dataverifiering

Håll underhållet utom räckhåll för den komprometterade klienten

Borgs append-only-lagring bevarar committad segmentdata, men en klient kan fortfarande ändra den synliga arkivlistan; återställning och komprimering kräver den dokumenterade administrativa proceduren. Begränsa fjärrsäkerhetskopians autentiseringsuppgift till Borgs serverkommando, inte ett obegränsat shell- eller filsystemsinlogg som skulle kunna kringgå dessa skydd. Med restic, granska keep-within-vägledningen för append-only-retention. Före allt underhåll som kan ta bort historik, inspektera repositoriets hälsa och förhandsgranska urvalet från en betrodd maskin.

• Övervaka åldern på den senaste lyckade kopian, databasens tillväxt, cacheutrymme och ledigt utrymme i båda ändar.
• Om en återställning misslyckas, bevara det ursprungliga arkivet och loggarna innan du försöker reparera eller städa upp.
• Om jobbet lyckas men förväntade filer saknas, granska arkivets innehåll och exkluderingsmönster innan du ändrar kvarhållningen.
• Avsluta övningen genom att öppna filer och köra applikationskontroller isolerat; håll produktionsmål utanför återställningskommandot.

Officiell dokumentation: Borg: endast tillägg-operation och underhåll · restic: bevarande och överväganden för endast tillägg