Restauration d’un dossier à partir de la sauvegarde avec duplicity

Pour une raison obscure, ma dernière tentative de mise à jour de Nextcloud a échoué et laissé le contenu du dossier dans un état instable. J’ai donc récupéré la dernière version stable depuis la sauvegarde de la veille.

sudo pip install --upgrade b2
sudo duplicity restore --force --file-to-restore path/to/nextcloud -t now b2://[applicationKeyId]:[application key]@[B2 bucket name] /path/to/nextcloud

De l’importance de la sauvegarde dans l’auto-hébergement

Le 29 au soir, mon Pi a fait une petite chute d’une vingtaine de centimètre lorsque le câble d’alimentation s’est pris dans l’un des pieds de ma chaise de bureau. J’ai d’abord cru que la chute avait été sans conséquences. Mais l’allumage d’une LED rouge fixe et l’extinction de la LED verte m’ont rapidement convaincu du contraire.

Après une tentative infructueuse de relancer le serveur, je retire la carte SD du Pi afin de l’examiner et constate une très légère pliure à sa surface. J’extrais la carte, l’insère dans un lecteur afin de vérifier son contenu. Pas de partitions détectées et montées automatiquement. C’est mauvais signe. Je teste un montage manuel, la réponse est sans appel : « mauvais type de système de fichiers, option erronée, superbloc erroné sur /dev/sdg, page de code ou programme auxiliaire manquant, ou autre erreur.« . Par ailleurs, la carte SD est particulièrement chaude au toucher lorsque je la retire du lecteur. Une seule conclusion s’impose, la carte SD est morte.

Je vérifie le contenu de mon fichier .hubic_credentials en local et demande l’état de la chaîne de sauvegarde :

duplicity collection-status cf+hubic://<container> 

Une sauvegarde complète date de la veille (28 janvier), je me lance dans une première récupération locale des données avec :

duplicity restore --force -t now cf+hubic://<container> data

Une fois en possession d’une nouvelle carte SD, j’ai donc réinstallé Raspbian pour pouvoir réinstaller mon serveur. A ce stade, j’ai la chance d’avoir passé plusieurs heures à écrire un script Ansible me permettant de déployer automatiquement mes différents services à partir de la sauvegarde effectuée par duplicity. Tout fonctionne plutôt bien, jusqu’à ce qu’on arrive à la récupération des fichiers sur hubic, où un nombre non négligeable de requête termine en erreur 404 et oblige à relancer le script jusqu’à obtenir une réponse. Pas vraiment de solution de ce côté-là à part changer d’endroit pour le stockage de la sauvegarde. Les requêtes en erreur finissant en général par répondre après un laps de temps aléatoire pouvant aller jusqu’à plusieurs jours. Bref, cette solution n’est pas satisfaisante du tout !

Après pas loin d’une dizaine d’heure de tentative, l’ensemble des fichiers nécessaires à duplicity est finalement disponible en local sur le système d’exploitation tout neuf. C’est le moment de tester les différents services. Wallabag et Shaarli fonctionne directement avec l’ensemble des données accessible. Ce n’est malheureusement pas le cas de Gitea, FreshRSS et Nextcloud.

Petit tour dans les logs de FreshRSS : « Access to database is denied« . J’arrête le service mysql, le redémarre et rafraîchis la page. Bingo ! L’interface s’affiche.

Pour Gitea, le problème se situe également du côté de la base de donnée et le ticket correspondant sur le projet est le numéro 2979 . Après connexion à la base, un simple

 set global innodb_large_prefix = `ON`; 

résous le problème. L’ensemble des données est présent. Pas de perte.

En ce qui concerne Nextcloud, le problème est à chercher du côté de la configuration de la sauvegarde. En effet, en y regardant de plus près, il semble que pour limiter la taille de la sauvegarde, je n’avais configuré que la sauvegarde du dossier data, au moment de la mise en place. En fait, après analyse, il s’avère que c’est bien pire, le dossier semble être présent dans la sauvegarde, mais pas son contenu. Étrange. Rien de catastrophique néanmoins, les données présentes sur mon instance Nextcloud sont toutes synchronisées soit sur mon ordinateur, soit sur mon téléphone, et par ailleurs, l’instance ne contient aucune donnée critique qui n’ait elle-même fait l’objet d’une sauvegarde sur un autre support.

Côté réinstallation, j’ai configuré Nextcloud pour utiliser la base existante réimportée à partir de la sauvegarde. Au passage, j’en ai profité pour faire la mise à jour vers la version 15. Les contacts, les calendriers et les tâches sont revenus à partir de la sauvegarde, j’ai perdu au passage l’enregistrement d’un événement, perte sans conséquence. La sauvegarde étant journalière, les pertes sont très limitées. Pour la partie fichier, c’est plus compliqué, puisque le dossier nextcloud du serveur n’est pas présent dans la sauvegarde. Les fichiers étant présent en totalité sur mon disque dur local, j’ai donc supprimé l’intégralité du contenu sur le serveur via l’interface web et j’ai forcé la synchronisation à partir du contenu local via le client Nextcloud.

Cette mésaventure m’a permis de tester ma procédure de sauvegarde et de déploiement automatisé du serveur et de ses services en conditions réelles. J’ai identifié quelques faiblesses, notamment du côté du système de stockage utilisé par duplicity, à savoir hubic et un problème de configuration du côté de la sauvegarde de Nextcloud. Au passage, pas de perte de données ou d’informations, ce qui est un point plus que positif. A cette occasion, j’en ai également profité pour mettre à jour certaines parties dépréciées de mon script Ansible. Des améliorations sont donc prévues, en particulier pour trouver une alternative correcte à hubic pour stocker les données de sauvegarde.

Procédure de restauration de sauvegarde… Surprise !

Depuis plusieurs mois donc, mes services auto-hébergés sont sauvegardés quotidiennement de façon automatique et incrémentale. Je suis en théorie protégé contre la perte de mes données en cas de panne matérielle du support de stockage de mon serveur. Ça, c’est la théorie, il me restait en l’occurrence à valider le processus de sauvegarde en m’assurant de la façon de restaurer les données.

J’ai donc commencé ces derniers jours l’écriture d’un script ansible permettant de redéployer automatiquement l’ensemble de mes services sur un nouveau serveur si besoin. L’occasion rêvée de vérifier que la restauration de sauvegarde fonctionne correctement.

Après configuration de duplicity sur la nouvelle machine, je tente donc de restaurer un fichier pris au hasard:

duplicity restore --file-to-restore path/to/wallabag/vendor/jdorn/sql-formatter/LICENSE.txt -t now cf+hubic:// test/LICENSE-restored.txt

J’obtiens une erreur dès les premières tentatives : No backup chains found, et lis au détour d’une page web qu’il faut à priori effectuer un list-current-files au préalable. Il faudra que je vérifie cette information lors du test réel de mon script sur un système vierge. Je découvre donc que duplicity récupère dans un premier temps tous les fichiers manifest. La récupération des fichiers se poursuit, et c’est le drame :

Giving up after 1 attempts. NoSuchObject: Object 'duplicity-inc.20180212T113006Z.to.20180213T113007Z.manifest.gpg' doesn't exist (HTTP 404)

L’un des fichiers n’est pas renvoyé par hubiC. Il est néanmoins visible dans l’interface, mais impossible de le récupérer, la requête effectuée par l’interface web retourne elle aussi une mauvaise erreur 404. Ce problème de manifeste manquant concerne une chaîne secondaire, mais impacte malheureusement l’ensemble de la collection. Impossible de restaurer les données via duplicity…

Continuer la lecture de « Procédure de restauration de sauvegarde… Surprise ! »

Sauvegarde distante avec duplicity

Suite à la migration de la majorité de mon nuage de services vers mon réseau en passant à l’auto-hébergement, la question de la sauvegarde des données est devenue cruciale. Côté cahier des charges, les principaux critères retenus étaient les suivants :

  • Sauvegarde externe géographiquement
  • Automatique
  • Chiffrée

Après de nombreuses recherches, j’ai décidé d’utiliser duplicity pour réaliser la sauvegarde et le service hubiC d’OVH pour le stockage des données sauvegardées. Voici donc la procédure utilisée pour mettre en place une sauvegarde incrémentale quotidienne, avec sauvegarde complète à intervalle régulier.

Pour commencer, il convient d’installer les composants nécessaires:

sudo aptitude install duplicity python-pip python-dev gcc
sudo pip2 install pyrax

Ayant décidé d’envoyer les sauvegardes dans mon espace hubiC, et afin de permettre à duplicity de communiquer avec hubiC, il faut au préalable autoriser l’application dans l’interface web du service. On va donc créer une nouvelle application, renseigner un nom, duplicity par exemple, et un domaine de redirection valant http://localhost/. On note ensuite les paramètres « Client ID » et « Client secret » qui serviront pour paramétrer la connexion à hubiC sur la machine source.

Le paramétrage s’effectue dans le fichier ~/.hubic_credentials :

[hubic]
email = your_email
password = your_password
client_id = api_client_id
client_secret = api_secret_key
redirect_uri = http://localhost/

On limite ensuite les droits liés au fichier:

chown 600 ~/.hubic_credentials

A ce stade, on peut faire un premier test afin de valider la configuration, par exemple, sauvegarder le répertoire test dans le conteneur test qui sera accessible à l’adresse suivante: https://hubic.com/home/browser/#test.

duplicity test cf+hubic://test

Pour lister le contenu du répertoire distant, la commande dédiée est:

duplicity list-current-files cf+hubic://test

Continuer la lecture de « Sauvegarde distante avec duplicity »

L’heure du renouveau

Mon petit nuage de service personnel commence à vieillir. Si la mise à jour des différents composants s’effectue généralement sans anicroche, certains d’entre eux consomment bien trop de ressources pour une utilisation mono-utilisateur. Constatant que mon dernier article faisant l’inventaire des services utilisés remonte à déjà deux ans, je me dois d’effectuer un petit rattrapage avant d’aller plus loin.

Voici donc un inventaire des services en septembre 2017 :

  • Baïkal : Pour la gestion des contacts et du calendrier.
  • Etherpad : Pour de l’édition collaborative.
  • FreshRSS : Pour la gestion des flux RSS.
  • Gitlab : Pour la gestion de code.
  • Seafile : Pour la gestion et le partage de fichiers.
  • Shaarli : Pour sauvegarder simplement des urls depuis n’importe quel support.
  • Wallabag : Pour la conservation d’article à lire ultérieurement.

La maintenance de deux de ces services : Gitlab, et Seafile dans une moindre mesure, commençaient à devenir de plus en plus lourde. Par ailleurs, l’empreinte mémoire de Gitlab semblait devenir toujours plus importante au fil du temps. Qu’on ne s’y trompe pas, les deux services sont plutôt bons. Gitlab est fantastique, mais n’est plus adapté aux petites configurations, il me semble davantage destiné aux communautés et aux entreprises désormais (ou à ceux qui veulent/peuvent réserver 2Go de mémoire vive à Gitlab). A ces considérations, s’ajoute le défi et l’objectif d’auto-héberger la majorité des services. Pour y arriver, je me suis donc fixé des impératifs en termes de consommations de ressources, dictés par le matériel à ma disposition. Enfin, c’est la décision d’aller vers davantage de simplicité qui prime, en essayant de trouver des composants stables, rapidement déployable et dont la sauvegarde est aisée.

Vous l’aurez compris, j’ai arrêté mes instances de Gitlab et de Seafile. A la place de Gitlab, j’utilise désormais Gitea, fork de gogs, pour une empreinte mémoire largement réduite et des fonctionnalités suffisantes. J’ai remplacé Seafile par Nextcloud; retour aux sources après avoir renoncé à Owncloud il y a deux ans. Au passage, j’en profite donc pour me séparer de Baïkal en utilisant les modules calendrier et contacts de Nextcloud.

J’obtiens donc le découpage suivant :

  • FreshRSS : Pour la gestion des flux RSS.
  • Gitea: Pour la gestion de code.
  • Nextcloud : Pour la gestion de fichiers, les contacts et les calendriers.
  • Shaarli : Pour sauvegarder simplement des urls depuis n’importe quel support.
  • Wallabag : Pour la conservation d’article à lire ultérieurement.

Voici donc l’état de mon nuage de service à l’automne 2017, quelques changements de services et du changement du côté de l’hébergement. A voir maintenant à l’utilisation si Nextcloud sera à la hauteur. La suite des opérations concerne désormais ce site en particulier, qui migrera à un endroit qui reste encore à définir.