[{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/backup/","section":"Tags","summary":"","title":"Backup","type":"tags"},{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/borg/","section":"Tags","summary":"","title":"Borg","type":"tags"},{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/dns/","section":"Tags","summary":"","title":"Dns","type":"tags"},{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/docker/","section":"Tags","summary":"","title":"Docker","type":"tags"},{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/password-manager/","section":"Tags","summary":"","title":"Password-Manager","type":"tags"},{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/pihole/","section":"Tags","summary":"","title":"Pihole","type":"tags"},{"content":"Méthode 1 : Restauration depuis Borg UI\nCette procédure s\u0026rsquo;applique à une stack Pi-hole v6 sauvegardée via Borg UI, avec :\nun script pre-backup qui déclenche l\u0026rsquo;export natif Teleporter (pihole-FTL --teleporter), produisant une archive zip cohérente contenant la configuration (pihole.toml) et le contenu de la base de blocage (gravity.db), sans jamais lire les fichiers SQLite live directement ; une source Borg couvrant cet export ainsi que le dossier dnsmasq.d (configuration DNS personnalisée statique). L\u0026rsquo;historique des requêtes DNS (statistiques de long terme, fichier pihole-FTL.db) n\u0026rsquo;est volontairement pas sauvegardé. Ce sont des logs, pas de la configuration : leur perte n\u0026rsquo;empêche en rien Pi-hole de refonctionner normalement après restauration. Ne restaurez jamais directement par-dessus les données de production sans étape intermédiaire. Étapes de restauration # 1. Arrêter la stack Pi-hole # cd /home/olivier/stacks/pihole docker compose down 2. Restaurer l\u0026rsquo;archive vers un dossier temporaire # Dans Borg UI : Archives → sélectionnez le repository Pi-hole → choisissez l\u0026rsquo;archive voulue → Restore vers un dossier temporaire :\n/local/restore-pihole 3. Redémarrer Pi-hole avec sa configuration existante # Contrairement à Nextcloud/Immich/Vaultwarden, il n\u0026rsquo;est pas nécessaire d\u0026rsquo;écraser le dossier data (/etc/pihole) avant de redémarrer : le Teleporter s\u0026rsquo;importe après coup, via l\u0026rsquo;interface web, sur une instance Pi-hole déjà démarrée (même une installation fraîche).\ndocker compose up -d Remettez en place dnsmasq.d si nécessaire :\ncp -a /home/olivier/backups/.../restore-pihole/local/pihole/dnsmasq.d/* \\ /home/olivier/stacks/pihole/dnsmasq.d/ docker compose restart pihole 4. Importer l\u0026rsquo;archive Teleporter via l\u0026rsquo;interface web # Connectez-vous à https://pihole.colmaris.fr, allez dans Settings → Teleporter, section Restore, et téléversez le fichier pihole-teleporter-latest.zip récupéré à l\u0026rsquo;étape 2.\nPour un restore scriptable/automatisé (sans passer par l\u0026rsquo;interface web), l\u0026rsquo;outil communautaire pihole_restore comble ce manque — le CLI officiel de Pi-hole v6 ne propose pas de commande de restauration native pour le moment. 5. Vérifier que tout fonctionne # Vérifiez que vos listes de blocage personnalisées, vos exceptions (whitelist/blacklist) et vos réglages DNS amont sont bien de retour. Testez une résolution DNS depuis un appareil du réseau, et vérifiez qu\u0026rsquo;un domaine publicitaire connu est bien bloqué.\nPoints critiques à retenir # Le Teleporter ne restaure pas l\u0026rsquo;historique de requêtes — c\u0026rsquo;est normal, ce n\u0026rsquo;est pas son rôle. L\u0026rsquo;import se fait après le démarrage, pas avant — contrairement aux autres stacks où on remet les fichiers en place puis on démarre. dnsmasq.d reste un dossier de fichiers bruts : une simple copie suffit, pas de traitement particulier. Testez cette procédure au moins une fois « à froid » avant d\u0026rsquo;en avoir besoin en situation réelle. Pour un crash total (serveur détruit, Borg UI indisponible), consultez Restaurer Pi-hole sans Borg UI.\nRestauration en mode dégradé (sans borgui) # Cette procédure s\u0026rsquo;applique quand Borg UI lui-même n\u0026rsquo;est plus disponible : serveur détruit, disque mort, tout scénario où vous repartez d\u0026rsquo;une machine vierge. Elle utilise uniquement le CLI Borg.\nPour une restauration simple (Borg UI toujours fonctionnel), consultez Restaurer Pi-hole depuis une sauvegarde Borg UI.\nPendant que Pi-hole est hors service, votre réseau perd sa résolution DNS filtrée. Si Pi-hole est votre seul serveur DNS configuré sur votre routeur/box, basculez temporairement vos appareils sur un DNS public (ex. 1.1.1.1) le temps de la restauration, pour ne pas couper l\u0026rsquo;accès Internet du foyer. Prérequis indispensables # La passphrase du repository Borg, stockée en dehors du serveur. Le docker-compose.yml et le .env de la stack Pi-hole, versionnés séparément (dépôt Git privé). L\u0026rsquo;emplacement du repository (chemin local, hôte SSH, ou remote cloud). Étapes de restauration # 1. Préparer la nouvelle machine # sudo apt update sudo apt install -y borgbackup 2. Récupérer l\u0026rsquo;accès au repository # export BORG_REPO=/chemin/ou/ssh/vers/le/repo/pihole export BORG_PASSPHRASE=\u0026#39;votre-passphrase-ici\u0026#39; borg list \u0026#34;$BORG_REPO\u0026#34; 3. Extraire l\u0026rsquo;archive # mkdir -p /home/olivier/restore-pihole cd /home/olivier/restore-pihole borg extract \u0026#34;$BORG_REPO\u0026#34;::NOM-DE-L-ARCHIVE Vous récupérez local/pihole/teleporter/pihole-teleporter-latest.zip et local/pihole/dnsmasq.d/.\n4. Reconstituer la stack Pi-hole # mkdir -p /home/olivier/stacks/pihole cd /home/olivier/stacks/pihole # Récupérez ici votre docker-compose.yml et votre .env mkdir -p data dnsmasq.d teleporter cp -a /home/olivier/restore-pihole/local/pihole/dnsmasq.d/* ./dnsmasq.d/ 5. Démarrer Pi-hole # docker compose up -d Une installation fraîche de Pi-hole démarre avec une configuration par défaut — c\u0026rsquo;est normal, l\u0026rsquo;étape suivante la remplace.\n6. Importer l\u0026rsquo;archive Teleporter # Connectez-vous à l\u0026rsquo;interface web de Pi-hole (attention : sur un nouveau serveur, l\u0026rsquo;adresse IP a peut-être changé — vérifiez votre configuration Traefik/DNS), puis Settings → Teleporter → Restore, et téléversez pihole-teleporter-latest.zip.\nPour un restore scriptable sans interface web, utilisez pihole_restore.\n7. Mettre à jour la résolution DNS du réseau # Si l\u0026rsquo;adresse IP du nouveau serveur diffère de l\u0026rsquo;ancienne, mettez à jour la configuration DNS de votre routeur/box pour pointer vers la nouvelle IP de Pi-hole.\n8. Réinstaller Borg UI et reconfigurer les Backup Plans # Une fois Pi-hole vérifié et fonctionnel, redéployez Borg UI et reconfigurez le Backup Plan Pi-hole.\nPoints critiques à retenir # La passphrase Borg est le point de défaillance numéro un — stockez-la en dehors du serveur qu\u0026rsquo;elle protège. docker-compose.yml et .env ne sont pas dans la sauvegarde Borg — prévoyez un dépôt Git privé séparé. Coupure DNS pendant la restauration : prévoyez un DNS de secours temporaire pour le réseau. Testez cette procédure de bout en bout au moins une fois, idéalement sur une VM isolée. ","date":"13 septembre 2026","externalUrl":null,"permalink":"/docs/resturation-pihole/","section":"Documentation","summary":"Méthode 1 : Restauration depuis Borg UI\nCette procédure s’applique à une stack Pi-hole v6 sauvegardée via Borg UI, avec :\nun script pre-backup qui déclenche l’export natif Teleporter (pihole-FTL --teleporter), produisant une archive zip cohérente contenant la configuration (pihole.toml) et le contenu de la base de blocage (gravity.db), sans jamais lire les fichiers SQLite live directement ; une source Borg couvrant cet export ainsi que le dossier dnsmasq.d (configuration DNS personnalisée statique). L’historique des requêtes DNS (statistiques de long terme, fichier pihole-FTL.db) n’est volontairement pas sauvegardé. Ce sont des logs, pas de la configuration : leur perte n’empêche en rien Pi-hole de refonctionner normalement après restauration. Ne restaurez jamais directement par-dessus les données de production sans étape intermédiaire. Étapes de restauration # 1. Arrêter la stack Pi-hole # cd /home/olivier/stacks/pihole docker compose down 2. Restaurer l’archive vers un dossier temporaire # Dans Borg UI : Archives → sélectionnez le repository Pi-hole → choisissez l’archive voulue → Restore vers un dossier temporaire :\n","title":"Restaurer Pi-hole depuis une sauvegarde","type":"docs"},{"content":" Méthode 1 : Restauration depuis Borg UI # Cette procédure s\u0026rsquo;applique à une stack Vaultwarden sauvegardée via Borg UI, avec :\nun script pre-backup qui déclenche la commande native vaultwarden backup (intégrée au binaire depuis les versions récentes), produisant un instantané SQLite cohérent sans dépendance externe ; une source Borg pointant directement vers le dossier data complet, à l\u0026rsquo;exception du fichier SQLite live et de ses journaux de transaction (exclus car potentiellement incohérents en cours d\u0026rsquo;écriture). Vaultwarden contient l\u0026rsquo;intégralité de vos mots de passe et informations sensibles. Traitez chaque étape de cette restauration avec la même rigueur de confidentialité que l\u0026rsquo;original : dossiers temporaires non exposés publiquement, suppression des copies intermédiaires une fois la restauration validée. Ne restaurez jamais directement par-dessus les données de production sans étape intermédiaire. Cette procédure passe systématiquement par un dossier de staging temporaire pour vous laisser une chance de vérifier le contenu avant d\u0026rsquo;écraser quoi que ce soit. Étapes de restauration (Borg UI toujours fonctionnel) # 1. Arrêter la stack Vaultwarden # cd /home/olivier/stacks/vaultwarden docker compose down Ne redémarrez rien tant que la restauration n\u0026rsquo;est pas terminée.\n2. Restaurer l\u0026rsquo;archive vers un dossier temporaire # Dans Borg UI : Archives → sélectionnez le repository Vaultwarden → choisissez l\u0026rsquo;archive à la date voulue → Restore vers un dossier temporaire, par exemple :\n/local/restore-vaultwarden Ne restaurez jamais directement vers les chemins de production à cette étape.\n3. Remettre en place le dossier data # Sauvegardez d\u0026rsquo;abord l\u0026rsquo;existant par précaution :\ncd /home/olivier/stacks/vaultwarden mv data data.old Puis copiez le contenu restauré vers l\u0026rsquo;emplacement de production :\ncp -a /home/olivier/backups/.../restore-vaultwarden/data \\ /home/olivier/stacks/vaultwarden/data 4. Remettre en place la base de données # Le fichier restauré s\u0026rsquo;appelle db-backup-latest.sqlite3 (nom fixe donné par le script pre-backup), pas db.sqlite3. Renommez-le :\ncd /home/olivier/stacks/vaultwarden/data mv db-backup-latest.sqlite3 db.sqlite3 Supprimez tout fichier db.sqlite3-wal ou db.sqlite3-shm résiduel avant de redémarrer :\nrm -f db.sqlite3-wal db.sqlite3-shm Si un ancien fichier -wal (journal de transactions) traîne à côté du db.sqlite3 restauré, SQLite tentera de rejouer ce journal au démarrage — potentiellement incohérent avec la base restaurée, avec un risque réel de corruption. C\u0026rsquo;est documenté explicitement dans le wiki officiel de Vaultwarden.\n5. Redémarrer la stack # docker compose up -d docker compose logs -f vaultwarden Surveillez les logs au démarrage : Vaultwarden doit ouvrir la base sans erreur.\n6. Vérifier que tout fonctionne # Connectez-vous à l\u0026rsquo;interface web (https://vault.colmaris.fr), vérifiez que vos identifiants, dossiers et éléments partagés (sends) correspondent bien à la date de l\u0026rsquo;archive restaurée. Ouvrez une pièce jointe existante pour confirmer que le dossier attachments/ a bien suivi.\nPoints critiques à retenir # db.sqlite3-wal doit être supprimé avant de redémarrer si vous restaurez le snapshot généré par vaultwarden backup — c\u0026rsquo;est le point d\u0026rsquo;échec le plus courant lors d\u0026rsquo;une restauration Vaultwarden. Le nom de fichier compte : Vaultwarden n\u0026rsquo;ouvrira que db.sqlite3, pas db-backup-latest.sqlite3. Le renommage à l\u0026rsquo;étape 4 est obligatoire. db.sqlite3-shm n\u0026rsquo;a pas besoin d\u0026rsquo;être restauré : c\u0026rsquo;est un fichier de mémoire partagée recréé automatiquement par SQLite. Reconnexion nécessaire : après une restauration, les sessions actives (extensions navigateur, applications mobiles) demandent généralement une nouvelle authentification. Testez cette procédure au moins une fois « à froid » avant d\u0026rsquo;en avoir besoin en situation réelle. Méthode 2 : Restauration d\u0026rsquo;urgence en cas de crash total (sans Borg UI) # Si Borg UI et son serveur hôte ont disparu, la logique générale est identique à celle détaillée dans Restaurer Nextcloud sans Borg UI — installez le CLI Borg sur la nouvelle machine, accédez au repository via sa passphrase (stockée en dehors du serveur), puis :\nexport BORG_REPO=/chemin/ou/ssh/vers/le/repo/vaultwarden export BORG_PASSPHRASE=\u0026#39;votre-passphrase-ici\u0026#39; borg list \u0026#34;$BORG_REPO\u0026#34; mkdir -p /home/olivier/restore-vaultwarden cd /home/olivier/restore-vaultwarden borg extract \u0026#34;$BORG_REPO\u0026#34;::NOM-DE-L-ARCHIVE Reconstituez ensuite docker-compose.yml et .env depuis leur emplacement de sauvegarde séparé (dépôt Git privé), replacez le dossier data restauré, appliquez les étapes 4 à 6 ci-dessus (renommage de la base, suppression du -wal, démarrage, vérification), puis redéployez Borg UI et reconfigurez le Backup Plan pour que les sauvegardes reprennent normalement.\nComme pour les autres stacks, la passphrase Borg et les fichiers docker-compose.yml/.env ne sont pas inclus dans la sauvegarde elle-même — assurez-vous de les avoir stockés ailleurs avant d\u0026rsquo;en avoir besoin. ","date":"13 septembre 2026","externalUrl":null,"permalink":"/docs/restauration-vaultwarden/","section":"Documentation","summary":"Méthode 1 : Restauration depuis Borg UI # Cette procédure s’applique à une stack Vaultwarden sauvegardée via Borg UI, avec :\n","title":"Restaurer Vaultwarden depuis une sauvegarde","type":"docs"},{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/self-hosted/","section":"Tags","summary":"","title":"Self-Hosted","type":"tags"},{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"13 septembre 2026","externalUrl":null,"permalink":"/tags/vaultwarden/","section":"Tags","summary":"","title":"Vaultwarden","type":"tags"},{"content":"","date":"10 septembre 2026","externalUrl":null,"permalink":"/tags/immich/","section":"Tags","summary":"","title":"Immich","type":"tags"},{"content":" Méthode 1 : Restauration depuis Borg UI # Cette procédure s\u0026rsquo;applique à une stack Immich sauvegardée via Borg UI, avec :\nun script pre-backup qui dumpe la base PostgreSQL en SQL brut (non compressé, pour une déduplication optimale) ; une source Borg pointant directement vers le dossier library (les photos et vidéos originales) ; le volume nommé model-cache (modèles de machine learning) volontairement exclu, puisqu\u0026rsquo;il se retélécharge automatiquement. À utiliser en cas de panne, de corruption de données, ou de migration vers un nouveau serveur — tant que Borg UI et son serveur hôte fonctionnent toujours. Pour un crash total, consultez l\u0026rsquo;article dédié : Restaurer Immich sans Borg UI.\nNe restaurez jamais directement par-dessus les données de production sans étape intermédiaire. Cette procédure passe systématiquement par un dossier de staging temporaire pour vous laisser une chance de vérifier le contenu avant d\u0026rsquo;écraser quoi que ce soit. Étapes de restauration # 1. Arrêter la stack Immich # Avant tout, arrêtez complètement la stack pour qu\u0026rsquo;aucun processus n\u0026rsquo;écrive dans la bibliothèque ou la base pendant la restauration.\ncd /home/olivier/stacks/immich docker compose down Ne redémarrez rien tant que la restauration n\u0026rsquo;est pas terminée.\n2. Restaurer l\u0026rsquo;archive vers un dossier temporaire # Dans Borg UI : Archives → sélectionnez le repository Immich → choisissez l\u0026rsquo;archive à la date voulue → sélectionnez tout son contenu (immich-library, immich-staging) → Restore vers un dossier temporaire, par exemple :\n/local/restore-immich Ne restaurez jamais directement vers les chemins de production à cette étape.\n3. Remettre en place la bibliothèque # Sauvegardez d\u0026rsquo;abord l\u0026rsquo;existant par précaution :\ncd /home/olivier/stacks/immich mv library library.old Puis copiez le contenu restauré vers l\u0026rsquo;emplacement de production (celui défini par UPLOAD_LOCATION dans votre .env) :\ncp -a /home/olivier/backups/.../restore-immich/immich-library \\ /home/olivier/stacks/immich/library 4. Redémarrer uniquement PostgreSQL # docker compose up -d database docker compose ps # attendre l\u0026#39;état \u0026#34;healthy\u0026#34; 5. Réimporter le dump SQL # Supprimez le contenu de la base actuelle et recréez-la (remplacez les valeurs par celles de votre fichier .env) :\ndocker exec -i immich_postgres psql -U \u0026lt;DB_USERNAME\u0026gt; \\ -d postgres -c \u0026#34;DROP DATABASE IF EXISTS \u0026lt;DB_DATABASE_NAME\u0026gt;;\u0026#34; docker exec -i immich_postgres psql -U \u0026lt;DB_USERNAME\u0026gt; \\ -c \u0026#34;CREATE DATABASE \u0026lt;DB_DATABASE_NAME\u0026gt;;\u0026#34; Puis réimportez le dump restauré :\ncat /chemin/vers/restore-immich/immich-staging/db/immich-db-latest.sql | \\ docker exec -i immich_postgres psql -U \u0026lt;DB_USERNAME\u0026gt; \\ -d \u0026lt;DB_DATABASE_NAME\u0026gt; 6. Redémarrer la stack complète # docker compose up -d docker compose ps # vérifier que tout est healthy 7. Relancer les jobs de réindexation # Contrairement à Nextcloud, Immich n\u0026rsquo;a pas de commande occ. Une fois connecté à l\u0026rsquo;interface web, allez dans Administration → Jobs et relancez manuellement :\nExtraction de métadonnées (Metadata Extraction) Génération de miniatures (Thumbnail Generation) Reconnaissance faciale (Face Detection), si vous l\u0026rsquo;utilisez Cela permet à Immich de resynchroniser son index avec les fichiers restaurés.\n8. Vérifier que tout fonctionne # Connectez-vous à l\u0026rsquo;interface web d\u0026rsquo;Immich et vérifiez que vos albums, photos et métadonnées correspondent bien à la date de l\u0026rsquo;archive restaurée. Vérifiez aussi les logs :\ndocker logs immich_server Points critiques à retenir # Restaurez toujours vers un dossier de staging d\u0026rsquo;abord, jamais directement par-dessus les données de production. Le dump SQL contient la structure exacte de la base : sur un nouveau serveur, vérifiez que DB_USERNAME / DB_PASSWORD dans le .env correspondent à ce que PostgreSQL attend. model-cache n\u0026rsquo;a pas besoin d\u0026rsquo;être restauré : c\u0026rsquo;est un volume de modèles de machine learning qui se retélécharge automatiquement au démarrage. Testez cette procédure au moins une fois « à froid » avant d\u0026rsquo;en avoir besoin en situation réelle. Méthode 2 : Restauration d\u0026rsquo;urgence en cas de crash total (sans Borg UI) # Cette procédure s\u0026rsquo;applique quand Borg UI lui-même n\u0026rsquo;est plus disponible : serveur détruit, disque mort, incendie, vol — tout scénario où vous repartez d\u0026rsquo;une machine vierge. Elle utilise uniquement le CLI Borg, sans interface graphique.\nPour une restauration simple (Borg UI toujours fonctionnel), consultez Restaurer Immich depuis une sauvegarde Borg UI — plus rapide et plus sûre grâce à l\u0026rsquo;interface.\nCette procédure suppose que votre repository Borg est accessible depuis la nouvelle machine (stockage externe survivant, NAS, ou copie off-site / cloud mirror). Si votre unique copie du repository était sur le disque qui a crashé, il n\u0026rsquo;y a rien à restaurer — d\u0026rsquo;où l\u0026rsquo;importance d\u0026rsquo;un mirroir hors-site. Prérequis indispensables # Avant de commencer, vous avez besoin de trois choses qui ne sont pas dans le repository Borg lui-même :\nLa passphrase du repository Borg — sans elle, les archives sont définitivement illisibles. Le docker-compose.yml et le .env de la stack Immich — ils ne sont pas sauvegardés par le script pre-backup actuel. Versionnez-les dans un dépôt Git privé séparé. L\u0026rsquo;emplacement du repository (chemin local, hôte SSH, ou remote cloud via rclone). Si vous ne stockez pas encore ces trois éléments en dehors de votre serveur Immich/Borg UI, faites-le avant d\u0026rsquo;en avoir besoin. Étapes de restauration # 1. Préparer la nouvelle machine # sudo apt update sudo apt install -y borgbackup borg --version 2. Récupérer l\u0026rsquo;accès au repository # Stockage local ou disque externe reconnecté :\nexport BORG_REPO=/mnt/backup-externe/borg-repos/immich Repository distant en SSH :\nexport BORG_REPO=ssh://user@serveur-distant:22/chemin/vers/immich Renseignez la passphrase :\nexport BORG_PASSPHRASE=\u0026#39;votre-passphrase-ici\u0026#39; 3. Vérifier l\u0026rsquo;intégrité et lister les archives disponibles # borg check \u0026#34;$BORG_REPO\u0026#34; borg list \u0026#34;$BORG_REPO\u0026#34; Si le message repository is locked apparaît :\nborg break-lock \u0026#34;$BORG_REPO\u0026#34; 4. Extraire l\u0026rsquo;archive vers un dossier de staging # mkdir -p /home/olivier/restore-immich cd /home/olivier/restore-immich borg extract \u0026#34;$BORG_REPO\u0026#34;::NOM-DE-L-ARCHIVE Cette commande recrée l\u0026rsquo;arborescence complète (immich-library/, immich-staging/db/immich-db-latest.sql) dans le dossier courant.\n5. Reconstituer la stack Immich # Recréez le dossier de la stack et récupérez docker-compose.yml / .env depuis leur emplacement de sauvegarde séparé :\nmkdir -p /home/olivier/stacks/immich cd /home/olivier/stacks/immich # Récupérez ici votre docker-compose.yml et votre .env Copiez la bibliothèque restaurée à son emplacement :\ncp -a /home/olivier/restore-immich/local/immich-library ./library 6. Démarrer uniquement PostgreSQL # docker compose up -d database docker compose ps # attendre l\u0026#39;état \u0026#34;healthy\u0026#34; 7. Réimporter le dump SQL # docker exec -i immich_postgres psql -U \u0026lt;DB_USERNAME\u0026gt; \\ -c \u0026#34;CREATE DATABASE \u0026lt;DB_DATABASE_NAME\u0026gt;;\u0026#34; cat /home/olivier/restore-immich/local/immich-staging/db/immich-db-latest.sql | \\ docker exec -i immich_postgres psql -U \u0026lt;DB_USERNAME\u0026gt; \\ -d \u0026lt;DB_DATABASE_NAME\u0026gt; 8. Démarrer la stack complète # docker compose up -d docker compose ps 9. Relancer les jobs de réindexation # Depuis Administration → Jobs dans l\u0026rsquo;interface web, relancez l\u0026rsquo;extraction de métadonnées et la génération de miniatures pour resynchroniser l\u0026rsquo;index avec les fichiers restaurés.\n10. Réinstaller Borg UI et reconfigurer les Backup Plans # Une fois Immich vérifié et fonctionnel, redéployez Borg UI sur la nouvelle machine et reconfigurez les Backup Plans pour que les futures sauvegardes reprennent normalement.\nPoints critiques à retenir # La passphrase Borg est le point de défaillance numéro un — stockez-la impérativement en dehors du serveur qu\u0026rsquo;elle protège. docker-compose.yml et .env ne sont pas dans la sauvegarde Borg actuelle. Prévoyez un dépôt Git privé pour ces fichiers de configuration. Vérifiez régulièrement que votre repository a bien une copie hors-site. Testez cette procédure de bout en bout au moins une fois, idéalement sur une VM isolée. ","date":"10 septembre 2026","externalUrl":null,"permalink":"/docs/restauration-immich/","section":"Documentation","summary":"Méthode 1 : Restauration depuis Borg UI # Cette procédure s’applique à une stack Immich sauvegardée via Borg UI, avec :\n","title":"Restaurer Immich depuis une sauvegarde Borg (Borg UI \u0026 CLI)","type":"docs"},{"content":"","date":"9 septembre 2026","externalUrl":null,"permalink":"/tags/apiculture/","section":"Tags","summary":"","title":"Apiculture","type":"tags"},{"content":"Ce blog rassemble le carnet de bord de mon activité d\u0026rsquo;apiculteur et de maraîcher : les saisons, les récoltes, les essaims, les galères et les réussites.\nVous y trouverez aussi une section Documentation où je note mes procédures techniques (sauvegardes, infra self-hosted\u0026hellip;), et une Galerie pour les photos.\n","date":"9 septembre 2026","externalUrl":null,"permalink":"/posts/bienvenue/","section":"Blog","summary":"Ce blog rassemble le carnet de bord de mon activité d’apiculteur et de maraîcher : les saisons, les récoltes, les essaims, les galères et les réussites.\nVous y trouverez aussi une section Documentation où je note mes procédures techniques (sauvegardes, infra self-hosted…), et une Galerie pour les photos.\n","title":"Bienvenue sur le rucher du Colmaris","type":"posts"},{"content":"","date":"9 septembre 2026","externalUrl":null,"permalink":"/tags/disaster-recovery/","section":"Tags","summary":"","title":"Disaster-Recovery","type":"tags"},{"content":"","date":"9 septembre 2026","externalUrl":null,"permalink":"/tags/mara%C3%AEchage/","section":"Tags","summary":"","title":"Maraîchage","type":"tags"},{"content":"","date":"9 septembre 2026","externalUrl":null,"permalink":"/tags/nextcloud/","section":"Tags","summary":"","title":"Nextcloud","type":"tags"},{"content":" Méthode 1 : Restauration standard via Borg UI # Cette procédure s\u0026rsquo;applique à une stack Nextcloud sauvegardée via Borg UI, avec :\nun script pre-backup qui dumpe la base PostgreSQL en SQL brut (non compressé, pour une déduplication optimale) ; des sources Borg pointant directement vers les dossiers ncdata et redis (pas de tar/gzip, pour permettre un vrai incrémental au niveau des blocs). À utiliser en cas de panne, de corruption de données, ou de migration vers un nouveau serveur — tant que Borg UI et son serveur hôte fonctionnent toujours. Pour un crash total (serveur détruit, Borg UI indisponible), consultez l\u0026rsquo;article dédié : Restaurer Nextcloud sans Borg UI.\nNe restaurez jamais directement par-dessus les données de production sans étape intermédiaire. Cette procédure passe systématiquement par un dossier de staging temporaire pour vous laisser une chance de vérifier le contenu avant d\u0026rsquo;écraser quoi que ce soit. Étapes de restauration # 1. Arrêter la stack Nextcloud # Avant tout, arrêtez complètement la stack pour qu\u0026rsquo;aucun processus n\u0026rsquo;écrive dans ncdata ou la base pendant la restauration.\ncd /home/olivier/stacks/nextcloud docker compose down Ne redémarrez rien tant que la restauration n\u0026rsquo;est pas terminée.\n2. Restaurer l\u0026rsquo;archive vers un dossier temporaire # Dans Borg UI : Archives → sélectionnez le repository Nextcloud → choisissez l\u0026rsquo;archive à la date voulue → sélectionnez tout son contenu (ncdata, redis, nextcloud-staging) → Restore vers un dossier temporaire, par exemple :\n/local/restore-nextcloud Ne restaurez jamais directement vers les chemins de production à cette étape.\n3. Remettre en place les fichiers ncdata # Sauvegardez d\u0026rsquo;abord l\u0026rsquo;existant par précaution :\ncd /home/olivier/stacks/nextcloud mv ncdata ncdata.old Puis copiez le contenu restauré vers l\u0026rsquo;emplacement de production :\ncp -a /home/olivier/backups/.../restore-nextcloud/ncdata \\ /home/olivier/stacks/nextcloud/ncdata Faites de même pour redis si besoin. Son contenu est du cache de session : généralement non critique à restaurer.\n4. Redémarrer uniquement PostgreSQL # docker compose up -d postgres docker compose ps # attendre l\u0026#39;état \u0026#34;healthy\u0026#34; 5. Réimporter le dump SQL # Supprimez le contenu de la base actuelle et recréez-la (remplacez les valeurs par celles de votre fichier .env) :\ndocker exec -i nextcloud-postgres psql -U \u0026lt;NEXTCLOUD_DB_USER\u0026gt; \\ -d postgres -c \u0026#34;DROP DATABASE IF EXISTS \u0026lt;NEXTCLOUD_DB_NAME\u0026gt;;\u0026#34; docker exec -i nextcloud-postgres psql -U \u0026lt;NEXTCLOUD_DB_USER\u0026gt; \\ -c \u0026#34;CREATE DATABASE \u0026lt;NEXTCLOUD_DB_NAME\u0026gt;;\u0026#34; Puis réimportez le dump restauré :\ncat /chemin/vers/restore-nextcloud/db/nextcloud-db-latest.sql | \\ docker exec -i nextcloud-postgres psql -U \u0026lt;NEXTCLOUD_DB_USER\u0026gt; \\ -d \u0026lt;NEXTCLOUD_DB_NAME\u0026gt; 6. Redémarrer la stack complète # docker compose up -d docker compose ps # vérifier que tout est healthy 7. Désactiver le mode maintenance et réparer # Nextcloud peut démarrer automatiquement en mode maintenance après une restauration.\ndocker exec -u www-data nextcloud php occ maintenance:mode --off docker exec -u www-data nextcloud php occ maintenance:repair docker exec -u www-data nextcloud php occ files:scan --all 8. Vérifier que tout fonctionne # Connectez-vous à l\u0026rsquo;interface web de Nextcloud et vérifiez que fichiers, contacts, calendriers et paramètres correspondent bien à la date de l\u0026rsquo;archive restaurée. Vérifiez aussi les logs :\ndocker logs nextcloud Points critiques à retenir # Restaurez toujours vers un dossier de staging d\u0026rsquo;abord, jamais directement par-dessus les données de production. Le dump SQL contient la structure exacte de la base : sur un nouveau serveur, vérifiez que NEXTCLOUD_DB_USER / NEXTCLOUD_DB_PASSWORD dans le .env correspondent à ce que PostgreSQL attend. Redis n\u0026rsquo;est pas critique : c\u0026rsquo;est du cache de session/verrous. Le perdre force une reconnexion des utilisateurs, sans perte de données réelle. Testez cette procédure au moins une fois « à froid » (instance de test ou VM) avant d\u0026rsquo;en avoir besoin en situation réelle. Une sauvegarde jamais restaurée n\u0026rsquo;est pas une sauvegarde fiable. Méthode 2 : Restauration d\u0026rsquo;urgence en CLI (Crash total / Sans Borg UI) # Cette procédure s\u0026rsquo;applique quand Borg UI lui-même n\u0026rsquo;est plus disponible : serveur détruit, disque mort, incendie, vol — tout scénario où vous repartez d\u0026rsquo;une machine vierge. Elle utilise uniquement le CLI Borg, sans interface graphique.\nPour une restauration simple (Borg UI toujours fonctionnel), consultez Restaurer Nextcloud depuis une sauvegarde Borg UI — plus rapide et plus sûre grâce à l\u0026rsquo;interface.\nCette procédure suppose que votre repository Borg est accessible depuis la nouvelle machine (stockage externe survivant, NAS, ou copie off-site / cloud mirror). Si votre unique copie du repository était sur le disque qui a crashé, il n\u0026rsquo;y a rien à restaurer — d\u0026rsquo;où l\u0026rsquo;importance d\u0026rsquo;un mirroir hors-site. Prérequis indispensables # Avant de commencer, vous avez besoin de trois choses qui ne sont pas dans le repository Borg lui-même :\nLa passphrase du repository Borg — sans elle, les archives sont définitivement illisibles. Elle doit être stockée dans un gestionnaire de mots de passe séparé du serveur (Bitwarden, Vaultwarden hébergé ailleurs, coffre papier, etc.). Le docker-compose.yml et le .env de la stack Nextcloud — ils ne sont pas sauvegardés par le script pre-backup actuel. Idéalement, versionnez-les dans un dépôt Git privé séparé, ou ajoutez-les comme source Borg dédiée. L\u0026rsquo;emplacement du repository (chemin local, hôte SSH, ou remote cloud via rclone) — notez-le quelque part en dehors du serveur lui-même. Si vous ne stockez pas encore ces trois éléments en dehors de votre serveur Nextcloud/Borg UI, faites-le avant d\u0026rsquo;en avoir besoin. Une sauvegarde de données sans sa configuration ni sa passphrase ne permet pas une restauration complète. Étapes de restauration # 1. Préparer la nouvelle machine # Installez Docker et Docker Compose sur le nouvel hôte, puis installez le CLI Borg :\nsudo apt update sudo apt install -y borgbackup borg --version 2. Récupérer l\u0026rsquo;accès au repository # Selon où vit votre repository :\nStockage local ou disque externe reconnecté :\nexport BORG_REPO=/mnt/backup-externe/borg-repos/nextcloud Repository distant en SSH :\nexport BORG_REPO=ssh://user@serveur-distant:22/chemin/vers/nextcloud Renseignez la passphrase (récupérée depuis votre gestionnaire de mots de passe) :\nexport BORG_PASSPHRASE=\u0026#39;votre-passphrase-ici\u0026#39; 3. Vérifier l\u0026rsquo;intégrité et lister les archives disponibles # borg check \u0026#34;$BORG_REPO\u0026#34; borg list \u0026#34;$BORG_REPO\u0026#34; Repérez le nom de l\u0026rsquo;archive à restaurer (format habituel : nom du plan + horodatage).\nSi le message repository is locked apparaît (crash pendant un run précédent) :\nborg break-lock \u0026#34;$BORG_REPO\u0026#34; 4. Extraire l\u0026rsquo;archive vers un dossier de staging # Créez un dossier de travail et extrayez-y l\u0026rsquo;archive :\nmkdir -p /home/olivier/restore-nextcloud cd /home/olivier/restore-nextcloud borg extract \u0026#34;$BORG_REPO\u0026#34;::NOM-DE-L-ARCHIVE Cette commande recrée l\u0026rsquo;arborescence complète (ncdata/, redis/, nextcloud-staging/db/nextcloud-db-latest.sql) dans le dossier courant.\nPour n\u0026rsquo;extraire qu\u0026rsquo;une partie (ex. seulement la base de données) :\nborg extract \u0026#34;$BORG_REPO\u0026#34;::NOM-DE-L-ARCHIVE local/nextcloud-staging 5. Reconstituer la stack Nextcloud # Recréez le dossier de la stack et récupérez docker-compose.yml / .env depuis leur emplacement de sauvegarde séparé (dépôt Git privé, autre sauvegarde) :\nmkdir -p /home/olivier/stacks/nextcloud cd /home/olivier/stacks/nextcloud # Récupérez ici votre docker-compose.yml et votre .env Copiez les données restaurées à leur emplacement :\ncp -a /home/olivier/restore-nextcloud/local/ncdata ./ncdata cp -a /home/olivier/restore-nextcloud/local/redis ./redis 6. Démarrer uniquement PostgreSQL # docker compose up -d postgres docker compose ps # attendre l\u0026#39;état \u0026#34;healthy\u0026#34; 7. Réimporter le dump SQL # docker exec -i nextcloud-postgres psql -U \u0026lt;NEXTCLOUD_DB_USER\u0026gt; \\ -c \u0026#34;CREATE DATABASE \u0026lt;NEXTCLOUD_DB_NAME\u0026gt;;\u0026#34; cat /home/olivier/restore-nextcloud/local/nextcloud-staging/db/nextcloud-db-latest.sql | \\ docker exec -i nextcloud-postgres psql -U \u0026lt;NEXTCLOUD_DB_USER\u0026gt; \\ -d \u0026lt;NEXTCLOUD_DB_NAME\u0026gt; 8. Démarrer la stack complète # docker compose up -d docker compose ps 9. Réparer et vérifier l\u0026rsquo;intégrité de Nextcloud # docker exec -u www-data nextcloud php occ maintenance:mode --off docker exec -u www-data nextcloud php occ maintenance:repair docker exec -u www-data nextcloud php occ files:scan --all 10. Mettre à jour les domaines de confiance # Sur un nouveau serveur, l\u0026rsquo;IP ou le nom d\u0026rsquo;hôte peut avoir changé. Vérifiez et corrigez si besoin :\ndocker exec -u www-data nextcloud php occ config:system:get trusted_domains docker exec -u www-data nextcloud php occ config:system:set trusted_domains 1 --value=votre-domaine.fr 11. Réinstaller Borg UI et reconfigurer les Backup Plans # Une fois Nextcloud vérifié et fonctionnel, redéployez Borg UI sur la nouvelle machine et reconfigurez les Backup Plans (voir l\u0026rsquo;article sur la mise en place initiale) pour que les futures sauvegardes reprennent normalement.\nPoints critiques à retenir # La passphrase Borg est le point de défaillance numéro un. Sans elle, toutes les données du repository sont irrécupérables — stockez-la impérativement en dehors du serveur qu\u0026rsquo;elle protège. docker-compose.yml et .env ne sont pas dans la sauvegarde Borg actuelle. Prévoyez un dépôt Git privé (ou une sauvegarde séparée) pour ces fichiers de configuration, sans quoi vous devrez les réécrire de mémoire en pleine crise. Vérifiez régulièrement que votre repository a bien une copie hors-site (cloud mirror, disque externe stocké ailleurs, serveur distant) — un repository local uniquement ne protège pas contre la perte du serveur lui-même. Testez cette procédure de bout en bout au moins une fois, idéalement sur une VM isolée, avant d\u0026rsquo;en avoir besoin en urgence réelle. ","date":"9 septembre 2026","externalUrl":null,"permalink":"/docs/restauration-nextcloud/","section":"Documentation","summary":"Méthode 1 : Restauration standard via Borg UI # Cette procédure s’applique à une stack Nextcloud sauvegardée via Borg UI, avec :\n","title":"Restaurer Nextcloud depuis une sauvegarde Borg (Borg UI \u0026 CLI)","type":"docs"},{"content":"Je m\u0026rsquo;appelle Olivier. Apiculteur et maraîcher de métier, je documente ici mon activité au fil des saisons, mes photos, et quelques notes techniques sur mon infrastructure self-hosted.\n","externalUrl":null,"permalink":"/about/","section":"À propos","summary":"Je m’appelle Olivier. Apiculteur et maraîcher de métier, je documente ici mon activité au fil des saisons, mes photos, et quelques notes techniques sur mon infrastructure self-hosted.\n","title":"À propos","type":"about"},{"content":"","externalUrl":null,"permalink":"/posts/","section":"Blog","summary":"","title":"Blog","type":"posts"},{"content":"","externalUrl":null,"permalink":"/categories/","section":"Categories","summary":"","title":"Categories","type":"categories"},{"content":"Notes techniques sur mon infrastructure self-hosted (Nextcloud, Immich, sauvegardes Borg\u0026hellip;). Rédigées pour moi-même le jour où j\u0026rsquo;en aurai besoin — mais accessibles à tous.\n","externalUrl":null,"permalink":"/docs/","section":"Documentation","summary":"Notes techniques sur mon infrastructure self-hosted (Nextcloud, Immich, sauvegardes Borg…). Rédigées pour moi-même le jour où j’en aurai besoin — mais accessibles à tous.\n","title":"Documentation","type":"docs"},{"content":"Quelques images du terrain, des ruches et des récoltes.\n","externalUrl":null,"permalink":"/gallery/","section":"Galerie","summary":"Quelques images du terrain, des ruches et des récoltes.\n","title":"Galerie","type":"gallery"},{"content":"Bienvenue sur mon carnet numérique. Vous y trouverez le récit de mon activité d\u0026rsquo;apiculteur et de maraîcher, mes photos, et quelques procédures techniques que je documente pour moi-même (et pour qui cela peut servir).\n","externalUrl":null,"permalink":"/","section":"Le Rucher de Colmaris","summary":"Bienvenue sur mon carnet numérique. Vous y trouverez le récit de mon activité d’apiculteur et de maraîcher, mes photos, et quelques procédures techniques que je documente pour moi-même (et pour qui cela peut servir).\n","title":"Le Rucher de Colmaris","type":"page"}]