Une sauvegarde est une question. Une restauration y répond.

Gardez le premier exercice délibérément petit

Cet exercice crée une base de données de notes jouet et une pièce jointe, capture les deux, puis les restaure dans une nouvelle base de données et un nouveau répertoire. Utilisez une machine Linux jetable avec le serveur PostgreSQL 17 et les utilitaires client correspondants, Bash et GNU coreutils. Elle ne doit contenir aucune donnée de production et n'avoir aucune connexion à des applications de production, du courrier sortant ou des tâches planifiées. Utilisez uniquement l'archive créée dans cet exercice.

Les commandes supposent un rôle de base de données préconfiguré, non superutilisateur, nommé restore_lab, autorisé à créer des bases de données de test, et une connexion OS du même nom pouvant s'authentifier localement. Le socket PostgreSQL est /var/run/postgresql sur le port 5432. Demandez à l'administrateur de préparer ce compte dans l'environnement jetable ; ce guide ne modifie pas les règles d'accès à la base de données. Vérifiez le point de terminaison avant de créer quoi que ce soit :

psql -h /var/run/postgresql -p 5432 -U restore_lab -d postgres -c '\conninfo' &&
pg_dump --version &&
pg_restore --version

Arrêtez-vous si l'hôte, le compte ou la version est inattendu. Gardez les clients et le serveur sur la même version majeure pour ce premier exercice. pg_dump ne peut pas vider un serveur plus récent que sa propre version majeure, et une cible de restauration plus ancienne n'est généralement pas garantie compatible. Voir limites de version de pg_dump. Exécutez chaque bloc séparément et arrêtez-vous en cas d'erreur. Les && gardes empêchent les commandes suivantes dans un bloc collé de s'exécuter après un échec ; ne continuez jamais vers le bloc suivant après un échec de création de base de données ou de répertoire.

Créez un enregistrement et son fichier correspondant

Les noms offvps_restore_source et offvps_restore_target doivent être inutilisés. Une base de données existante est une raison de s'arrêter et de choisir un nouvel exercice isolé, pas une raison de la supprimer. Créez un nouvel espace de travail sur le système de fichiers et la base de données source :

umask 077 &&
lab=$(mktemp -d "$PWD/offvps-restore.XXXXXX") &&
mkdir "$lab/source" "$lab/source/uploads" "$lab/bundle" "$lab/restore" &&
createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_source

Le nouvel espace de travail évite d'écraser un répertoire existant. mktemp crée un répertoire unique ; createdb crée une nouvelle base de données à partir du modèle sélectionné. Enregistrez ces deux marqueurs :

psql -X -v ON_ERROR_STOP=1 -h /var/run/postgresql -p 5432 \
  -U restore_lab -d offvps_restore_source \
  -c "CREATE TABLE notes (
        id integer PRIMARY KEY,
        body text NOT NULL,
        attachment text NOT NULL
      );
      INSERT INTO notes VALUES (1, 'restore-marker-01', 'marker.txt');" &&
printf '%s\n' 'restore-marker-01' > "$lab/source/uploads/marker.txt"

L'enregistrement indique quel fichier appartient à la note, et les deux contiennent le même marqueur. Cela rend visible une pièce jointe manquante ou une copie non concordante. -X évite les paramètres de démarrage personnels de psql et ON_ERROR_STOP s'arrête en cas d'erreur SQL ; voir options de script psql. Aucune application n'écrit dans ce jeu de données jouet.

Capturez la base de données et les fichiers comme un seul ensemble de restauration

pg_dump -h /var/run/postgresql -p 5432 -U restore_lab \
  --format=custom --file="$lab/bundle/notes.dump" offvps_restore_source &&
cp -a "$lab/source/uploads" "$lab/bundle/uploads" &&
pg_restore --list "$lab/bundle/notes.dump"

L'archive au format personnalisé est lue par pg_restore; un vidage SQL brut suit une procédure de restauration différente. Lister l'archive aide à confirmer que la table et les entrées de données attendues sont présentes. Un vidage de base de données cohérent ne synchronise pas automatiquement les téléversements externes. Pour une vraie application, utilisez sa procédure documentée de maintenance ou de pause d'écriture afin que l'arborescence de fichiers et la base de données décrivent le même instant. L'exercice jouet est déjà au repos.

Notez la version de la base de données, la version de l'application, le début et la fin de la capture et le chemin des fichiers à côté du paquet. Conservez les identifiants réels séparément sous des contrôles d'accès appropriés. Un vidage par base de données ne capture pas les rôles globaux ni les tablespaces ; un vrai plan de reprise doit également en tenir compte. La portée est décrite dans le guide de vidage SQL de PostgreSQL.

Restaurez dans de nouvelles cibles sans nettoyer une cible existante

createdb -h /var/run/postgresql -p 5432 -U restore_lab \
  --template=template0 offvps_restore_target &&
pg_restore -h /var/run/postgresql -p 5432 -U restore_lab \
  --dbname=offvps_restore_target --no-owner --no-acl \
  --single-transaction "$lab/bundle/notes.dump" &&
mkdir "$lab/restore/uploads" &&
cp -a "$lab/bundle/uploads/." "$lab/restore/uploads/"

La base de données cible est créée vide. La restauration omet intentionnellement --clean, ce qui pourrait supprimer des objets existants. --single-transaction fait réussir cette petite restauration de base de données comme une unité ou s'arrêter sans appliquer ses modifications partielles ; il ne peut pas être combiné avec des tâches parallèles. --no-owner et --no-acl simplifient la propriété pour ce rôle de test, donc cet exercice ne valide pas les rôles ni les permissions de production de l'application. Voir pg_restore.

La copie de fichier cible le nouveau répertoire de restauration, laissant la source intacte. GNU cp -a tente de préserver les attributs de fichier ; inspectez la propriété et l'accès pour le compte qui exécutera une vraie application. Copier des octets n'est pas un test des permissions applicatives. Voir option archive de cp.

Vérifiez la relation, pas seulement les codes de sortie

psql -X -h /var/run/postgresql -p 5432 -U restore_lab \
  -d offvps_restore_target -c "SELECT id, body, attachment FROM notes;" &&
cat "$lab/restore/uploads/marker.txt"

Les résultats attendus sont une ligne avec l'ID 1, le corps restore-marker-01 et la pièce jointe marker.txt, plus un fichier contenant restore-marker-01. Vérifiez que la source contient toujours sa ligne et son fichier d'origine. Pour votre vraie application, pointez aussi une instance isolée vers la base de données restaurée et le répertoire de téléversement, ouvrez des enregistrements représentatifs, récupérez une pièce jointe et testez les permissions de connexion prévues. Gardez les rappels, le courrier et les tâches contenus pendant cette opération.

Notez ce que vous avez prouvé et ce qui reste à faire

Les résultats attendus ci-dessus sont des critères d'exercice, pas des résultats déjà observés par OffVPS. Comme le premier exercice conserve tous les fichiers sur une seule machine, il n'offre aucune protection contre la perte de cette machine. Un vrai plan nécessite une copie protégée dans un domaine de défaillance séparé, des clés de déchiffrement utilisables, une rétention et un chemin de récupération testé. Vérifiez les noms exacts de bases de données jetables et le répertoire avant le nettoyage ultérieur ; gardez la production en dehors de ce processus.

Répétez l'exercice après des changements importants et consignez les échecs aussi soigneusement que les succès. Un service de sauvegarde optionnel ne prouve pas le temps de récupération de votre application. Continuez avec la planification d'une tâche planifiée lorsque vous êtes prêt à automatiser la capture, tout en conservant un exercice de restauration séparé.