Configurez des tâches de sauvegarde distinctes pour les documents, les photos et l’état des applications, car ces jeux de données présentent des schémas de modification, des exigences de cohérence, des besoins de conservation et des procédures de restauration différents.
Une tâche unique et volumineuse est simple à planifier, mais difficile à comprendre en cas de panne. Un document supprimé nécessite un historique des versions, une photothèque perdue exige des originaux et des métadonnées durables, et une application reposant sur une base de données peut nécessiter un export coordonné ainsi que sa configuration avant de pouvoir démarrer. Des tâches distinctes permettent de tester chaque parcours de récupération indépendamment, tout en utilisant la même cible NAS ou hors site.
Définissez les unités de récupération avant de choisir les outils de sauvegarde
Commencez par répertorier les éléments qui doivent être restaurés ensemble. Un dossier de documents peut être utilisé indépendamment comme de simples fichiers. Une application photo peut nécessiter les originaux et l’état de la base de données. Un service auto-hébergé peut nécessiter un export de base de données, la configuration, les secrets, les fichiers Compose et certains volumes persistants.
Un article de 2026 sur les fichiers, machines virtuelles et bases de données distingue les fichiers, les machines virtuelles et les bases de données selon le mécanisme nécessaire à leur récupération. La leçon utile est d’organiser les sauvegardes selon la logique de restauration plutôt que selon le dossier racine le plus facile à sélectionner.
Créez un petit tableau de couverture indiquant le jeu de données, la source de référence, la méthode de sauvegarde, la planification, la conservation, l’exigence de cohérence, la cible hors site et le test de restauration. Tout élément qui ne peut pas être intégré au tableau ne fait pas encore partie d’un plan de sauvegarde complet.
Donnez aux documents une conservation orientée vers les versions
Les documents sont généralement peu volumineux par rapport aux photos et sont fréquemment modifiés par des éditions, des renommages et des suppressions. L’exigence principale est souvent de pouvoir récupérer une version antérieure ou un fichier supprimé par erreur, plutôt que d’optimiser au maximum le débit de sauvegarde séquentielle.
Attribuez aux documents une destination et une politique de conservation propres afin de pouvoir récupérer les éditions, les renommages et les suppressions accidentelles sans supporter le coût de conservation beaucoup plus élevé des archives photo.
Excluez les caches et les fichiers temporaires qui peuvent être recréés, mais conservez les métadonnées et les autorisations des fichiers lorsqu’elles sont importantes. Lors des tests, restaurez un document bureautique modifié et un dossier supprimé au lieu de vérifier uniquement que les fichiers sont présents dans le dépôt.
Protégez séparément les originaux photo et les dérivés recréables
Les originaux photo et les vidéos personnelles sont généralement volumineux, principalement ajoutés par lots et difficiles, voire impossibles, à recréer. Leur tâche de sauvegarde doit privilégier l’intégralité des médias de référence, un transfert incrémentiel efficace, une durabilité hors site et une conservation suffisante pour résister à une suppression accidentelle.
Un article de 2026 sur les originaux, de la base de données et de la configuration distingue les ressources originales de l’état PostgreSQL, de la configuration et des dérivés générés. Cette séparation est utile au-delà d’Immich : les miniatures d’une application photo peuvent souvent être recréées, contrairement aux originaux familiaux.
Ne laissez pas une tâche lourde consacrée aux médias retarder les petites sauvegardes de configuration critiques. Si le transfert des photos dure plusieurs heures, planifiez séparément les tâches de documents et d’état des applications afin qu’elles puissent tout de même créer des points de récupération récents.
Capturez l’état des applications avec une cohérence applicative
Les répertoires d’applications actifs peuvent contenir des bases de données transactionnelles, des caches, des verrous, des files d’attente, des index et des fichiers générés. Une copie du système de fichiers effectuée pendant l’écriture d’une base de données peut être moins fiable qu’un petit export natif de la base de données combiné à la configuration de l’application.
Une conception pratique de serveur domestique pour la cohérence entre systèmes met en évidence la difficulté de protéger les photos, les bases de données intégrées et l’état des services avec un modèle de copie générique unique.
Le guide ZimaSpace associé sur les sauvegardes cohérentes de conteneurs de bases de données définit la limite précise : protégez un état cohérent de la base de données avant de traiter le volume environnant comme de simples fichiers.
Échelonnez les tâches et testez indépendamment les trois parcours de restauration
Attribuez à chaque tâche, lorsque cela est possible, son propre compte ou ses propres identifiants, espace de noms de destination, journal, système d’alerte, politique de nouvelle tentative et fenêtre de maintenance. Échelonnez les sauvegardes photo volumineuses par rapport aux vérifications du dépôt ou à la maintenance de la base de données afin qu’une charge de travail ne puisse pas monopoliser discrètement tout l’espace disque ou la fenêtre réseau.
Un cas de homelab datant de 2026 décrivant des fenêtres de sauvegarde séparées montre pourquoi il est plus facile de surveiller différents services lorsque la capture de leur base de données, la sauvegarde de leurs fichiers et leurs étapes hors site sont explicites.
Effectuez trois tests de restauration : récupérez une version d’un document, reconstruisez un petit sous-ensemble de photos avec ses métadonnées, puis démarrez une application à partir de son état sauvegardé sur une cible vierge. Les tâches distinctes ne sont efficaces que lorsqu’elles réduisent l’ambiguïté de récupération sans créer de dépendances cachées entre elles.
Assistance et conseils
Plus à lire

Comment adapter les politiques de redémarrage Docker aux bases de données, aux workers et aux applications web
Adaptez la politique de redémarrage au cycle de vie du service et à la signification de sa terminaison. Associez-la à des contrôles de santé...

Comment configurer les identifiants utilisateur des conteneurs sur plusieurs partages NAS
Associez l’UID/GID de chaque conteneur à ses partages NAS, utilisez des groupes partagés ou des ACL si nécessaire, et considérez PUID/PGID comme spécifiques à...

Comment configurer des profils Docker Compose pour des services optionnels de serveur domestique
Laissez les services requis sans profil et utilisez des profils pour les outils facultatifs. Testez les cibles directes et leurs dépendances au lieu de...

