6 MAANDEN VOORAF −28% · 1 JAAR VOORAF −50%Abonnementen vergelijken
PrivacyNodes
APPLICATIEOPERATIES

Een herstelchecklist die u kunt oefenen

Een back-up wordt operationeel nuttig wanneer een geautoriseerde beheerder de juiste gegevens in een geïsoleerde omgeving kan herstellen en de applicatie kan verifiëren. Oefen de afhankelijkheidsketen, niet alleen een commando dat met succes afsluit.

PrivacyNodes engineering-notities · Beoordeeld · 3 min leestijd

Definieer acceptabel verlies en uitval

Noteer het laatst acceptabele herstelpunt en de doeltijd om nuttige service te herstellen. Dit zijn applicatiedoelen, geen PrivacyNodes-SLA. Als het verliezen van een uur aan data onacceptabel is, kan een dagelijkse kopie dat doel alleen niet halen. Kies een databasemethode voor back-up die past bij je werklast en versie.

Verkrijg een wegwerpbaar doel, het applicatie-artefact en geautoriseerde herstelreferenties via beschermde opslag. Bevestig wie het herstellen van klantgegevens goedkeurt en hoe de testomgeving buitenverkeer voorkomt. Herstel niet over de draaiende productiedatabase of een bestaande map.

Inventariseer de volledige applicatiestatus

Noem voor de rapportage-API PostgreSQL, uploads, exports die niet reproduceerbaar zijn, configuratie, verwijzingen naar encryptiesleutels, DNS en externe afhankelijkheden. Maak onderscheid tussen een wegwerpbare cache en een wachtrij met klantwerk dat reconciliatie nodig heeft. Een containerimage beschrijft software, niet alle persistente status.

Repetitieverslag om tijdens de oefening in te vullen
RecordJouw waarde
Artefact- en configuratieversieExacte identificaties
Databaseback-up en herstelpuntGekozen archief en tijdstempel
Uploadsnapshot en consistentiegrensSnapshot, pad en overeenkomstplan
Wegwerpbaar doelGeverifieerde omgeving en lege bestemming
Referenties en goedkeurderAlleen beschermde verwijzingen
Start, voltooiing, ontbrekende stappenWaargenomen resultaten, geen schattingen

Begrijp wat de back-up bevat

PostgreSQL documenteert logische dumps, bestandssysteemback-ups en continue archivering als verschillende strategieën. Een pg_dump archief dekt één database; clusterbrede rollen en tablespaces vereisen aparte overweging. De client kan geen nieuwere major-version-server dumpen. Stem toolversies en strategie af op het doel; het kopiëren van een live datamap is niet automatisch consistent.

Inspecteer een archief voordat je herstelt. Het selecteren van een tabel met pg_restore neemt niet automatisch al zijn afhankelijkheden mee. De --clean -optie verwijdert bestaande objecten; een single-transaction-herstel kan niet combineren met parallelle jobs. Beoordeel opties voor de specifiek geïdentificeerde lege testdatabase.

Technische referentie: PostgreSQL back-up en herstel · PostgreSQL pg_dump · PostgreSQL pg_restore.

Controleer integriteit en herstel onafhankelijk

Repository-controles en functionele herstellen beantwoorden verschillende vragen. De gewone check van restic leest niet elk opgeslagen datapack; check --read-data voegt die leesbewerkingen toe en kan aanzienlijke bandbreedte verbruiken. Geen van beide bewijst dat de snapshot alles bevat wat de API nodig heeft.

Selecteer een specifieke snapshot en een nieuwe doelmap. Een niet-gekwalificeerde latest in een gedeelde repository kan een andere werklast selecteren. Een herstel kan bestanden overschrijven en een onderbreking kan gedeeltelijke resultaten achterlaten. Verifieer eerst de bestemming en laat productiebestanden en de oorspronkelijke repository ongemoeid.

Technische referentie: restic repository-controles · restic hersteldoelen.

Test het herstelde gedrag in afhankelijkheidsvolgorde

Herbouw de omgeving, herstel de database en bijbehorende uploads en start de API met staging-referenties. Houd workers gepauzeerd tot hun achterstand en bijeffecten duidelijk zijn. Schakel productie-e-mail, betalingsaanroepen en webhooks uit; gebruik een test-exportbestemming en consumeer nooit de productiewachtrij.

Gebruik een bekend testaccount om een record te lezen, de upload ervan te openen, toegangsbeperkingen te controleren en een kleine nieuwe export uit te voeren. Verifieer dat een ander testaccount de gegevens niet kan lezen. Vergelijk het gekozen herstelpunt met het laatst verwachte record. Registreer de werkelijke hersteltijd na de drill; schrijf niet vooraf een verzonnen succesresultaat.

Los schrijfeigenaarschap op vóór een echte cutover

Bepaal tijdens een incident welk systeem schrijfacties mag accepteren en hoe latere wijzigingen worden gereconcilieerd. Twee beschrijfbare kopieën kunnen uiteenlopen. Een drill documenteert deze beslissing zonder echt verkeer om te schakelen. Verwijder wegwerpbare data volgens je bewaarregels wanneer de oefening eindigt.

Corrigeer ontbrekende referenties, afhankelijkheden en validatiestappen na elke repetitie. Bewaar de runbook buiten de oorspronkelijke host en zorg dat een andere geautoriseerde beheerder deze kan vinden. De selecteerbare back-upoptie staat los van dit applicatieproces; bevestig scope en herstelprocedures in servicefeiten. Gebruik de releaseregistratie voor de implementatie die volgt.

Officiële referenties

Documentatie is beoordeeld voor dit artikel. Voorbeelden zijn plannings-oefeningen, geen commando's die op een PrivacyNodes-server zijn getest. Controleer de documentatie voor uw geïnstalleerde versie.