Comment vérifier une restauration Immich avant de mettre hors service l’ancien serveur

Ne mettez pas hors service l’ancien serveur Immich simplement parce que le nouveau tableau de bord se charge et que les photos apparaissent. Ne mettez l’ancien serveur hors service qu’une fois que le système restauré a confirmé la présence des utilisateurs, des albums, des personnes, de la recherche, d’originaux échantillonnés, de nouveaux téléversements, des tâches en arrière-plan, des redémarrages et d’une nouvelle sauvegarde, tandis que l’ancien hôte reste disponible comme solution de repli.

Maintenez l’ancien serveur éteint mais inchangé pendant la validation afin que deux instances n’acceptent pas de téléversements sur la base d’états divergents. Attribuez d’abord à l’hôte restauré une adresse de test contrôlée, établissez une référence à partir de l’ancien système et comparez les mêmes flux d’utilisation du foyer, plutôt que de vous fier à l’impression visuelle que la chronologie semble complète.

Conservez l’ancien serveur intact pendant l’établissement d’une référence de restauration

Avant le basculement, notez le nombre d’utilisateurs, le nombre d’éléments, quelques albums représentatifs, les personnes nommées, les favoris, les éléments partagés, les chemins des bibliothèques externes et plusieurs originaux d’exemple répartis sur différentes dates et différents utilisateurs. Notez également les versions d’Immich et de PostgreSQL utilisées sur l’ancien serveur, ainsi que les artefacts de sauvegarde utilisés pour la restauration. Les contrôles d’intégrité des dossiers ou du stockage constituent des étapes de validation utiles, mais ils ne remplacent pas la vérification des relations.

Le modèle de récupération de ZimaSpace pour restaurer une photothèque interrogeable considère les originaux, l’état du catalogue et de la base de données, ainsi que la configuration qui définit les chemins, comme une seule unité de récupération. C’est la bonne référence, car de simples fichiers image isolés ne peuvent pas prouver que l’appartenance aux albums, la propriété, les personnes et les relations de recherche ont été préservées.

Ne formatez pas les anciens disques, ne réutilisez pas définitivement son adresse IP et ne supprimez pas encore la dernière sauvegarde connue comme fonctionnelle. La cible de vérification doit rester réversible : si une relation critique manque, vous devez pouvoir consulter l’ancien état afin de déterminer si le problème vient de la sauvegarde, de la méthode de restauration, du mappage des chemins ou du nouvel environnement d’exécution.

Vérifiez les relations, pas seulement la visibilité des photos

Connectez-vous avec plusieurs utilisateurs attendus et vérifiez que chaque compte voit les bons éléments et partages. Ouvrez des albums connus, des personnes nommées, des favoris, des souvenirs ou d’autres relations propres au foyer qui seraient difficiles à reconstituer à partir des seuls fichiers. Comparez un petit échantillon avec la référence enregistrée sur l’ancien serveur.

Une discussion sur une migration Immich concernant des albums manquants après une restauration PostgreSQL montre pourquoi cela est important : les photos pouvaient rester présentes alors que l’état des albums avait disparu, et une nouvelle exportation de la base de données a ensuite modifié le résultat. Considérez cela comme un exemple concret prouvant qu’une connexion réussie ou une chronologie visible ne constitue pas un test de restauration complet.

Effectuez des recherches sur plusieurs éléments connus à l’aide des métadonnées et de toutes les fonctions visuelles ou de reconnaissance des personnes activées. Si les originaux sont présents mais que les relations ou les résultats de recherche manquent, déterminez si l’état concerné devait être restauré ou s’il est volontairement en cours de régénération. Ne mettez pas l’ancien serveur hors service tant que cette distinction n’est pas établie.

Testez les chemins de lecture, d’écriture, de dépendance et de redémarrage

Ouvrez directement d’anciennes photos et vidéos depuis le stockage restauré, puis téléversez un nouvel élément sans importance depuis un client mobile ou web. Vérifiez que son original est écrit au bon emplacement, qu’il apparaît pour le bon utilisateur et que ses tâches en arrière-plan progressent. Ne testez les bibliothèques externes et l’accès à distance qu’une fois le chemin local de lecture et d’écriture stabilisé.

Les tests de restauration doivent valider l’application après la copie des données. Un guide actuel sur les tests de reprise après sinistre recommande une validation au niveau de l’application incluant les bases de données, les permissions, les connexions réseau et les services, plutôt que de s’arrêter à la fin d’une tâche de sauvegarde ou de restauration. Redémarrez deux fois la pile Immich et redémarrez une fois le nouvel hôte. Après chaque cycle, vérifiez que les mêmes points de montage, utilisateurs, éléments d’exemple, base de données, proxy ou point d’accès local et comportements des tâches sont rétablis. Un service qui ne fonctionne que jusqu’au premier redémarrage de l’hôte n’a pas réussi sa migration.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Créez une nouvelle sauvegarde avant de fermer la fenêtre de retour arrière

Créez une nouvelle sauvegarde cohérente de la base de données et protégez l’étendue des médias et de la configuration requise par la conception de récupération. Restaurez au moins une petite cible de validation ou inspectez la sauvegarde avec le même processus que celui utilisé avant le basculement. Un serveur restauré qui ne peut pas produire sa propre sauvegarde récupérable ne doit pas devenir l’unique copie de production.

Faites fonctionner le nouvel hôte pendant une période d’observation définie, comprenant les téléversements habituels depuis les téléphones, la navigation, la recherche, le traitement en arrière-plan, la sauvegarde planifiée et au moins un cycle nocturne. Laissez l’ancien hôte éteint afin qu’il ne puisse pas provoquer de divergence d’état, mais conservez-le inchangé jusqu’à ce que le nouveau système traverse ces événements sans différences inexpliquées.

La décision de basculer définitivement exige la correspondance des relations critiques, des originaux lisibles, de nouvelles écritures réussies, des redémarrages stables et une nouvelle sauvegarde vérifiée.

Si des utilisateurs disparaissent, si les nombres divergent sensiblement, si des erreurs de chemin réapparaissent ou si la base de données signale des problèmes de cohérence, arrêtez la nouvelle instance et préservez les deux côtés avant toute investigation. Ce n’est qu’alors que l’ancien serveur pourra être effacé ou réaffecté.