Krypterede sikkerhedskopier, du faktisk kan gendanne.

Vælg repository-grænsen

Brug en separat destination og separate legitimationsoplysninger fra produktionsserveren. Kryptering på klientsiden kan beskytte lagrede kopier, men repository-adgangskoden eller nøglen skal sikkerhedskopieres privat. Mister du den, kan alle krypterede snapshots blive ubrugelige.

Indsaml ensartede data

Brug databaseindfødte dumps eller en applikationsunderstøttet snapshotprocedure. Sikkerhedskopier konfiguration, udrulningsinstruktioner og de beskyttede hemmeligheder, der kræves til gendannelse. Udelad kun midlertidige caches, når du ved, at de kan genopbygges.

Gør sletning sværere

Overvej et append-only- eller uforanderligt mål, hvor kildemaskinen ikke kan slette enhver historisk kopi. Hold opbevarings- og oprydningslegitimationsoplysninger adskilt, hvor det er muligt. Kryptering alene forhindrer ikke en kompromitteret server i at slette et skrivbart lager.

Planlæg kontroller og gendannelsesøvelser

Overvåg jobafslutningsstatus og alderen på den seneste gode sikkerhedskopi. Kør integritetskontroller af repository, som værktøjet understøtter. Gendan en prøve regelmæssigt, og udfør en komplet gendannelsesøvelse efter større applikationsændringer.

Adskil tilføjelse af en kopi fra sletning af historik

Et append-only-destinationsmål kan lade produktionsserveren tilføje snapshots, mens sletteadgangen bevares på en separat betroet maskine. Opbevaringsperioden skal stadig gennemgås omhyggeligt: forfalskede nyere snapshots kan underminere visse kalenderbaserede udvælgelsespolitikker. Læs værktøjets vejledning, kør en tør kørsel for opbevaring, og overvåg kapaciteten. Restics forget-handling vælger snapshots; pruning fjerner ikke-refererede lagrede data.

• Hold vedligeholdelseslegitimationsoplysninger til repositories væk fra produktionsmaskinen
• Kør en opbevaringsprøvekørsel, før sletning tillades
• Brug et nyt tomt mål for hver gendannelsesøvelse

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

Officiel dokumentation: Restic-opbevaring og oprydning

En gendannelsesøvelse med en beståelsesbetingelse

Vælg én realistisk fejl: en slettet fil, en tabt database eller en komplet genopbygning af maskinen. Gendan til en separat mappe eller isoleret vært. Bekræft filindhold, tilladelser og applikationens evne til at bruge dem. Registrér forløbet tid og eventuelle manuelle trin, der manglede i runbooken. En kontrol af repositoriet bekræfter en anden egenskab end en fungerende applikationsgendannelse.

• Gendan ikke oven på den kørende applikation som første test
• Bekræft, at krypteringsoplysningerne kan gendannes uafhængigt
• Giv alarm, hvis den nyeste vellykkede backup overskrider dit gendannelsesmål

Byg et gendannelsesmanifest, før du vælger undtagelser

List de ting, der ikke kan genskabes ved at geninstallere en pakke: databaseindhold, uploads, applikationskonfiguration, signerings- eller krypteringsnøgler og udrulningsversioner. Notér konsistensmetoden ved hvert element. Et databasedump hører til et defineret tidspunkt; kopiering af en travl databasemappe kan give et andet resultat. Opbevar repository-adgang, dens adgangsfrase og enhver Borg-nøgleeksport på et separat privat gendannelsessted. Test, at en erstatningsmaskine kan åbne repository'et, før den gøres til den eneste gendannelseskopi.

• Angiv gendannelsespunktmålet: hvor meget nyligt arbejde der må gå tabt. Fastlæg tidsplanen ud fra dette krav.
• Angiv målet for genopretningstid: hvor lang tid en genopbygning må tage. Medtag databaseimport og ændringer af DNS i prøvekørslen.
• Kontroller, at en udelukkelse beregnet til caches ikke også fjerner uploads, containervoluminer eller beskyttet konfiguration.
• Brug dokumentationen til den installerede Borg-hovedversion; lagerformater og kommandoer er ikke udskiftelige på tværs af alle versioner.

Officiel dokumentation: Borg: kryptering, konsistens og gendannelse

Kontrollér lagrede data samt repository-metadata

Restics standardkontrol af repository og en gennemlæsningsverificering udfører forskelligt arbejde. Planlæg dataverificering med dens båndbredde- og køretidsomkostning i tankerne. Eksemplet kontrollerer en defineret femtedel af pack-filerne; efterfølgende planlagte kontroller skal bruge de øvrige fraktioner for at dække repositoryet. Et tilfældigt udvalgt delmængde giver ikke samme dækningsgaranti. Ingen af operationerne beviser, at applikationen kan starte med gendannede data.

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

Officiel dokumentation: restic: kontrol af repositories og dataverifikation

Hold vedligeholdelse uden for den kompromitterede klients rækkevidde

Borg append-only-lager bevarer committet segmentdata, men en klient kan stadig ændre den synlige arkivliste; gendannelse og komprimering kræver den dokumenterede administrative procedure. Begræns den eksterne backup-legitimationsoplysning til Borgs serverkommando, ikke et ubegrænset shell- eller filsystem-login, der kan omgå disse beskyttelser. Med restic skal du gennemgå keep-within-vejledningen for append-only-opbevaring. Før enhver vedligeholdelse, der kan fjerne historik, skal du inspicere repositoryets sundhed og forhåndsvise udvalget fra en betroet maskine.

• Overvåg alderen på den seneste vellykkede kopi, repository-vækst, cacheplads og ledig kapacitet i begge ender.
• Hvis en gendannelse mislykkes, skal det oprindelige repository og logfiler bevares, før der forsøges reparationer eller oprydning.
• Hvis jobbet lykkes, men de forventede filer mangler, skal du undersøge arkivets indhold og udelukkelsesmønstre, før du ændrer opbevaringen.
• Afslut øvelsen ved at åbne filer og køre applikationskontroller isoleret; hold produktionsdestinationer ude af gendannelseskommandoen.

Officiel dokumentation: Borg: append-only drift og vedligeholdelse · restic: opbevaring og append-only-overvejelser