Back-up en herstel naar tijdstip

Replicatie vervangt geen back-up. Iedere database is te herstellen naar ieder tijdstip in haar herstelvenster, en de onveranderbare kopie beschermt de productie.

Iedere database heeft een dagelijkse volledige back-up en doorlopende archivering van het transactielogboek, met archive_timeout 5 minuten. Het herstelvenster is 7 dagen bij ontwikkelen en beproeven en 30 dagen in reguliere productie, met behoud van de laatste volledige back-up van vóór het venster en het aansluitende transactielogboek.

Iedere database heeft een eigen bucket en een eigen back-upgebruiker in de realm platform van de objectopslag, naast de bucket per cluster voor de volumeback-up. Zo liggen bewaartermijn en beëindiging per database vast. De back-ups worden over de nacht gespreid, en de plug-in spreekt HTTPS met certificaatcontrole.

De back-up gebruikt een ObjectStore (barmancloud.cnpg.io/v1) met retentionPolicy 7d of 30d en compressie, en een dagelijkse ScheduledBackup met method plugin; het schema telt zes velden en begint met seconden. Omdat CloudNativePG 1.31 de ingebouwde back-upmethode naar objectopslag verwijdert, gebruikt de eerste levering direct de Barman Cloud-plug-in.

Iedere back-up heeft een kopie buiten de cel: de back-upvoorziening van RWS haalt de buckets ieder uur op, met een identiteit die alleen mag lezen. De achterstand van die kopie bepaalt het haalbare herstelpunt na verlies van de cel en wordt per database gemeten; boven 2 uur volgt een melding.

Na verlies van de cel is het herstelpunt de achterstand van de kopie buiten de cel: circa 1 uur, en bij de terugvaloptie van dagelijks ophalen tot 24 uur. Dat is een aanvaard restrisico, begrensd door de meting per database en de melding boven 2 uur.

Volumes, back-ups en de kopie buiten de cel zijn versleuteld: volumes en back-ups staan op schijven met LUKS2-versleuteling, en Cohesity versleutelt de kopie buiten de cel met sleutels van RWS. Versleuteling per volume is de optie voor bedrijfskritische productie.

Herstel naar tijdstip maakt een nieuw databasecluster in een afgeschermde naamruimte in hetzelfde applicatiecluster, zonder verbinding met de toepassing. Het schrijft de nieuwe tijdlijn naar een andere locatie en laat de bestaande database ongewijzigd tot de eigenaar het resultaat goedkeurt.

Herstel naar een gekozen tijdstip gebruikt een nieuw cluster met bootstrap.recovery uit de oorspronkelijke ObjectStore, met een targetTime inclusief tijdzone, en schrijft de nieuwe tijdlijn naar een andere ObjectStore. Het oorspronkelijke archief blijft intact; het herstel is pas geslaagd als de toepassing met de herstelde gegevens werkt.

De eigenaar controleert het herstelde databasecluster met een controlerol en keurt het goed. Bij productieherstel worden daarna de schrijvers gestopt, verhuizen adres en naam naar het nieuwe databasecluster, worden beheeraccount en leases vernieuwd en begint een nieuwe back-upreeks.

Na verlies van cluster of cel wordt de database uit haar eigen back-up of de kopie buiten de cel teruggezet, niet via de volumeback-up van het cluster. Na een aanval of verlies van de cel begint het herstel in de herstelomgeving, waar de kopie eerst wordt gecontroleerd, op de gastklasse van de werkervirtualisatie. Bij de terugkeer naar productie komt er een nieuw databasecluster op de opslagklasse normaal-blok uit de gecontroleerde kopie; verder gaat het als productieherstel.

Herstel naar tijdstip wordt ieder kwartaal beproefd. In reguliere productie is het gegevensverlies daarbij ten hoogste 5 minuten en het herstel binnen 4 uur voor een database tot 100 GB; bij ontwikkelen en beproeven moet de database opnieuw op te bouwen zijn.

De dienst is gereed als een database naar een gekozen tijdstip is hersteld en gecontroleerd in een afgeschermde kopie, de inloggegevens zonder onderbreking van de toepassing zijn vervangen en een beëindiging de gegevens volgens de bewaartermijn heeft behandeld. Voor reguliere productie komen de overname en het herstel uit de kopie buiten de cel erbij.

Bij beëindiging volgen een laatste applicatieconsistente back-up met gestopte schrijvers en de intrekking van leases, rollen en verbinding in het geheimenbeheer. Daarna verdwijnen adres, naam, certificaat, databasecluster en naamruimte; de back-ups verdwijnen pas na de bewaartermijn.