Comment restaurer une base de données Immich à partir d’une sauvegarde fiable

Une sauvegarde connue comme valide de la base de données Immich n’est utile que si vous la restaurez dans un état contrôlé et prouvez que la base de données récupérée pointe toujours vers les médias que votre serveur peut réellement voir.

Considérez la récupération comme une séquence, et non comme une simple commande d’importation. Préservez d’abord l’instance défaillante, identifiez la version d’Immich et l’horodatage de la sauvegarde, démarrez une cible de base de données propre et compatible, restaurez sans laisser l’application écrire d’abord dans un schéma vide, puis validez les comptes, les données de la chronologie, les chemins des médias et une nouvelle écriture. Si une étape est ambiguë, arrêtez-vous avant de remplacer la dernière copie récupérable.

Figez l’état défaillant avant toute restauration

Arrêtez les nouveaux téléversements et les écritures en arrière-plan sur l’instance Immich concernée avant de commencer la récupération. Enregistrez le fichier Compose actuel, les valeurs d’environnement, les chemins montés, les versions des images, les journaux récents et l’état de la base de données endommagée si le stockage le permet. Une base de données défaillante peut encore contenir des éléments permettant de comprendre ce qui s’est passé, et l’écraser supprime ces éléments.

Identifiez précisément la sauvegarde à laquelle vous comptez vous fier. Notez son horodatage, la manière dont elle a été créée, sa taille et si elle a déjà été restaurée à titre de test. Un dump SQL produit par la base de données est un actif de récupération différent d’une copie brute du répertoire de données PostgreSQL actif ; ne les considérez pas comme interchangeables.

Créez la cible de récupération dans un répertoire distinct ou une pile isolée lorsque cela est possible. Le critère de sortie de cette étape est simple : l’état défaillant d’origine est préservé, la sauvegarde choisie est en lecture seule et vous savez à quelle version du déploiement et à quels chemins de stockage la restauration doit se reconnecter.

Vérifiez que la sauvegarde peut réellement être restaurée

Inspectez la sauvegarde avant de la rejouer. Un dump SQL compressé doit se décompresser proprement et contenir un contenu reconnaissable de dump PostgreSQL plutôt qu’une archive vide produite par un pipeline défaillant. Si vous disposez de sommes de contrôle ou de résultats de vérification du dépôt, comparez-les maintenant au lieu de découvrir une corruption au milieu de la récupération.

Un dump PostgreSQL constitue un actif de récupération plus sûr qu’une simple copie d’un répertoire de base de données actif, car il est créé avec des outils tenant compte de la base de données et peut être rejoué dans une cible propre. Le modèle de sauvegarde par dump de base de données sépare également la base de données de la copie des médias, ce qui facilite la validation de chaque partie avant la récupération.

Vérifiez également que les médias et la configuration correspondant à la période de la sauvegarde existent toujours. Restaurer uniquement la base de données peut récupérer les utilisateurs, les albums, les métadonnées et les références aux fichiers, tout en laissant chaque ressource inutilisable si les chemins de la bibliothèque référencés sont absents. Ne continuez que lorsque le dump et l’ensemble des médias et de la configuration correspondent à un point de récupération connu.

Démarrez d’abord une cible de base de données propre et compatible

Adaptez la méthode de restauration à la version qui a créé la sauvegarde. Les versions actuelles d’Immich proposent la restauration de la base de données via Administration > Maintenance ainsi que dans le parcours d’intégration d’une nouvelle installation, tandis que les anciennes sauvegardes peuvent nécessiter des instructions manuelles spécifiques à la version ; le processus de restauration a changé avec la version v2.5.0.

Pour une nouvelle cible de récupération, ne laissez pas Immich exécuter les migrations normales sur un schéma vide avant que la restauration de la base de données soit prête. Si votre méthode de déploiement démarre l’application en même temps que PostgreSQL, utilisez les contrôles de restauration adaptés à la version afin que le serveur ne crée pas un état concurrent avant l’importation.

Si la base de données ne devient pas saine d’elle-même, arrêtez-vous et résolvez d’abord ce problème. Ne rejouez pas sans cesse la même sauvegarde dans une cible qui redémarre, manque d’espace disque ou utilise une disposition de stockage incompatible. Une cible propre et stable est un prérequis, et non une digression de dépannage.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Restaurez le dump une seule fois et arrêtez-vous à la première erreur

Restaurez le dump choisi dans la base de données préparée et capturez la sortie complète. Utilisez les outils et les options de base de données adaptés au format du dump afin qu’une erreur fasse échouer la restauration de manière visible, au lieu de laisser un schéma partiellement importé qui démarre tout de même.

Un ensemble de migration utilisable doit comprendre les ressources, l’état PostgreSQL et la configuration qui les reconnecte. Un ensemble de sauvegarde Immich complet inclut les ressources téléversées, une sauvegarde de base de données prise en charge et la configuration du déploiement, avec des tests de restauration servant à prouver que l’ensemble fonctionne. Conservez ces éléments ensemble afin que la destination puisse être associée à un seul point de récupération.

Après une importation réussie, démarrez l’application Immich et surveillez attentivement son premier démarrage. Si l’interface vous demande de créer un nouvel administrateur principal au lieu d’accepter les comptes existants, arrêtez-vous : cela indique fortement que la base de données restaurée n’est pas celle utilisée par Immich. Ne commencez pas à retéléverser des photos dans cet état vide.

Validez l’état de la base de données, les chemins des médias et une nouvelle écriture

Connectez-vous avec un compte existant et vérifiez la chronologie à différentes dates, anciennes et récentes. Ouvrez plusieurs originaux, inspectez des albums ou des favoris dont vous savez qu’ils existaient et confirmez que l’application peut résoudre les fichiers sous-jacents, au lieu d’afficher uniquement des lignes de la base de données.

L’état de la base de données, les fichiers de l’application, la configuration et les téléversements doivent correspondre au moment de la restauration. Utilisez une sauvegarde cohérente d’un conteneur de base de données comme modèle d’acceptation, et pas simplement le fait que PostgreSQL démarre.

Enfin, téléversez une photo destinée à être supprimée, attendez son traitement normal, vérifiez qu’elle subsiste après un redémarrage d’Immich et un redémarrage de l’hôte, puis supprimez-la via l’application. Si les comptes, les anciennes ressources et la nouvelle écriture fonctionnent tous normalement, effectuez une nouvelle sauvegarde de l’état récupéré avant toute mise à niveau de version. Dans le cas contraire, revenez aux éléments préservés de l’incident ou à une sauvegarde connue comme valide plus ancienne, plutôt que d’aggraver les dommages.