SQL Academy · Les

Uw herstelprocedures testen

Een back-up die u niet kunt herstellen, is nutteloos.

Les 3 van 413 stappen

Uw herstelprocedures testen is een gratis SQL Academy-les op CoddyKit. Dit is les 3 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject SQL Academy. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus SQL Academy bevat in totaal 4 lessen.

Een back-up die je niet kunt herstellen is waardeloos

Veel teams investeren tijd in het instellen van geautomatiseerde back-ups, maar controleren nooit of die back-ups daadwerkelijk kunnen worden gebruikt om gegevens te herstellen. Een back-up die tijdens het herstel mislukt, is helemaal geen back-up.

In deze les leer je hoe je hersteltests uitvoert: hoe je controleert of je back-ups werken voordat een echte calamiteit je dwingt daar op de harde manier achter te komen.

Wat houdt een hersteltest in?

Bij een hersteltest neem je een back-upbestand en laad je het in een database — meestal een aparte testinstantie — waarna je query's uitvoert op die database om te bevestigen dat de gegevens volledig en consistent zijn.

De stappen zijn: 1) verkrijg het back-upbestand. 2) herstel het in een sandboxomgeving. 3) voer validatiequery's uit. 4) vergelijk de resultaten met productie.

Een referentieopname maken ter vergelijking

Voordat je een herstel kunt verifiëren, heb je een referentie nodig — een bekende set aantallen en controlesommen uit productie waarmee je de herstelde kopie kunt vergelijken.

Voer dit uit op je productiedatabase en leg de resultaten vast:

SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

Rijtellingen na herstel verifiëren

Nadat de back-up in een testdatabase is hersteld, voer je dezelfde query uit en vergelijk je de aantallen. Als de aantallen overeenkomen, is de basisstructuur van het herstel in orde.

Een verschil laat je onmiddellijk zien dat er tijdens het maken of herstellen van de back-up gegevens verloren zijn gegaan — nog voordat je productie aanraakt.

-- Run on the RESTORED test database
SELECT
  'orders'        AS tbl, COUNT(*) AS row_count FROM orders
UNION ALL
SELECT
  'customers'     AS tbl, COUNT(*) AS row_count FROM customers
UNION ALL
SELECT
  'order_items'   AS tbl, COUNT(*) AS row_count FROM order_items;

De meest recente gegevens controleren

Rijtellingen bevestigen de hoeveelheid, maar niet de actualiteit. Controleer of de herstelde database recente records bevat — de back-up hoort gegevens te bevatten tot het moment waarop deze is gemaakt.

SELECT
  MAX(created_at) AS latest_order,
  MIN(created_at) AS oldest_order,
  COUNT(*)        AS total_orders
FROM orders;

Referentiële integriteit valideren

Zelfs als de rijtellingen overeenkomen, kan een herstel verweesde rijen achterlaten — onderliggende records waarvan het bovenliggende record niet meer bestaat. Dit gebeurt vaak wanneer vreemde sleutels tijdens het maken of herstellen van de back-up niet worden afgedwongen.

Gebruik een LEFT JOIN om verweesde orderregels te detecteren:

SELECT
  oi.id       AS orphaned_item_id,
  oi.order_id AS missing_order_id
FROM order_items oi
LEFT JOIN orders o ON o.id = oi.order_id
WHERE o.id IS NULL;

Corruptie detecteren met een controlesom

Genereer voor kritieke tabellen een controlesom van de gegevens om beschadiging op bitniveau te detecteren. In PostgreSQL kun je MD5 combineren met een cast van de volledige rij.

Als de controlesom uit productie verschilt van die van de herstelde kopie, zijn de gegevens op een bepaald moment gewijzigd of beschadigd.

SELECT
  MD5(string_agg(row_data, ',' ORDER BY row_data)) AS table_checksum
FROM (
  SELECT CAST(ROW(id, customer_id, total, created_at) AS TEXT) AS row_data
  FROM orders
) sub;

Een tabel voor herstelvalidatie maken

Maak een speciale tabel voor een validatielogboek om de geschiedenis van je hersteltests bij te houden. Leg elke testuitvoering vast met de datum van de back-up, het aantal herstelde rijen en de vraag of de validatie is geslaagd.

CREATE TABLE IF NOT EXISTS restore_validation_log (
  id             SERIAL PRIMARY KEY,
  backup_taken_at TIMESTAMP NOT NULL,
  restored_at    TIMESTAMP NOT NULL DEFAULT NOW(),
  table_name     VARCHAR(100) NOT NULL,
  expected_rows  INT NOT NULL,
  actual_rows    INT NOT NULL,
  passed         BOOLEAN NOT NULL
);

Een validatieresultaat invoegen

Voeg na elke hersteltest een rij toe aan het validatielogboek. Zo ontstaat een controleerbaar spoor waaruit blijkt dat back-ups zijn getest en zie je in de loop van de tijd een patroon van geslaagde en mislukte tests.

INSERT INTO restore_validation_log
  (backup_taken_at, table_name, expected_rows, actual_rows, passed)
VALUES
  ('2024-06-09 02:00:00', 'orders',      15482, 15482, TRUE),
  ('2024-06-09 02:00:00', 'customers',    8201,  8201,  TRUE),
  ('2024-06-09 02:00:00', 'order_items', 47310, 47310, TRUE);

De validatiegeschiedenis opvragen

Bekijk het validatielogboek regelmatig om achteruitgang te signaleren. Een back-up die vorige week slaagde maar deze week mislukt, wijst op een probleem in je back-uppijplijn dat onmiddellijk moet worden onderzocht.

SELECT
  backup_taken_at,
  table_name,
  expected_rows,
  actual_rows,
  passed,
  CASE
    WHEN passed THEN 'OK'
    ELSE 'MISMATCH - investigate!'
  END AS status
FROM restore_validation_log
ORDER BY backup_taken_at DESC, table_name;

Herstel naar een bepaald tijdstip verifiëren

Moderne databases ondersteunen herstel naar een bepaald tijdstip (PITR), waarmee je met behulp van een basisback-up plus WAL-archieven naar elk moment kunt herstellen.

Om te controleren of PITR werkt, herstel je naar een bekend tijdstempel en controleer je dat een record dat na dat tijdstip is gemaakt NIET voorkomt in de herstelde database:

-- After a PITR restore to '2024-06-09 03:00:00',
-- this order (created at 03:45) should NOT exist:
SELECT id, created_at, total
FROM orders
WHERE created_at > '2024-06-09 03:00:00'
ORDER BY created_at
LIMIT 5;
-- Zero rows = PITR worked correctly

Korte controle

Welke van de volgende query's is het nuttigst om verweesde onderliggende records te detecteren nadat je een back-up hebt hersteld?

Beantwoord dit in de interactieve les

Samenvatting van de les: je hersteltests uitvoeren

In deze les heb je geleerd waarom hersteltests een verplicht onderdeel zijn van elke back-upstrategie en hoe je ze met SQL implementeert:

Referentieopnamen — leg productierijtellingen vast voordat je gaat testen.
Vergelijking van rijtellingen — voer dezelfde query uit op de herstelde database en vergelijk de resultaten.
Controle op actualiteit — bevestig dat de nieuwste records overeenkomen met het verwachte back-upvenster.
Referentiële integriteit — gebruik LEFT JOIN om verweesde onderliggende rijen te vinden.
Controlesomvalidatie — detecteer beschadiging op bitniveau met MD5-aggregaties.
Validatielogboektabel — houd elke testuitvoering bij voor een controleerbare geschiedenis.
PITR-verificatie — bevestig dat herstel naar een bepaald tijdstip op het juiste moment uitkomt.

Een back-up is slechts zo goed als de laatste geslaagde hersteltest. Plan deze controles regelmatig en behandel elke mislukking als een kritiek incident.

Gratis beginnen

Leer SQL met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 46
Lessen: 183

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Uw herstelprocedures testen” gratis?

Ja — de volledige tekst van “Uw herstelprocedures testen” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus SQL Academy wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus SQL Academy bevat in totaal 4 lessen.

Wat leer ik in “Uw herstelprocedures testen”?

Een back-up die u niet kunt herstellen, is nutteloos. Je oefent met SQL Academy door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met SQL Academy te beginnen?

Ervaring vooraf is niet nodig. SQL Academy op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 3 van 4.

Hoe lang duurt de les “Uw herstelprocedures testen”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over SQL Academy?

Ja. Elke les over SQL Academy bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

← Terug naar SQL Academy