Liste des imports
(chargement...)
Upload local (.sql / .dump / .gz / .bz2 / .zip)
Depuis S3 (.dump ou .sql)
Depuis WAL-G
wal-g backup-fetch -> cluster temporaire :5433 -> pg_dump | restore dans rescuedb_walg_<label>_<dbname> sur :5432.
1
Comparer 2 sauvegardes
2
Choisir quoi corriger
3
Préparer un rapport
4
Tester en bac à sable
5
Appliquer en production
Comparer 2 sauvegardes
Choisissez la sauvegarde de référence (état avant l'incident) et celle à analyser (état actuel après l'incident).
Que voulez-vous récupérer depuis la sauvegarde de référence ?
Choix rapide en 1 clic — ou activez le mode avancé pour détailler ligne par ligne, colonne par colonne.
◯ Tout récupérer recommandé
Restaure les tables manquantes et les lignes manquantes depuis la sauvegarde. Les ajouts récents en prod sont préservés. Non destructif.
◯ Récupérer seulement les lignes manquantes
Ne touche pas aux structures de tables. Ajoute uniquement les lignes présentes dans la sauvegarde mais absentes de l'état actuel. Non destructif.
◯ Choisir table par table (avancé)
Pour DBA / dev qui veulent détailler chaque action : sélection ligne par ligne, colonne par colonne, filtres SQL.
Voulez-vous générer un rapport pour votre équipe avant d'appliquer ?
Cette étape est facultative. Les rapports incluent votre sélection — pas seulement le diff brut.
Tester en bac à sable
On va créer une copie de votre base avec les corrections appliquées. Vous pourrez la tester avec votre staging avant d'appliquer en production.
{{-- Choix de la methode de generation du SQL --}}Méthode de génération du correctif
Comment voulez-vous appliquer le correctif ?
Arrêt de la VM
L'arrêt lance un poweroff propre. Le SaaS détruira ensuite la VM. Vos données sur cette VM seront perdues — sauvegardez vos exports avant.