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.

Auto-hébergement : quel matériel ?

Depuis quelques mois déjà, j’ai tenté l’expérience de l’auto-hébergement pour deux des services que j’utilise. Je ne vais pas m’attarder sur les contraintes de l’hébergement chez soi, d’autres l’ont déjà fait. Si vraiment cela devenait indispensable, cela ferait alors l’objet d’un billet spécifique. L’auto-hébergement donc, étape supplémentaire dans ma quête d’indépendance numérique.

J’ai effectué mes premiers tests avec un Raspberry Pi modèle B de première génération faisant office de serveur. Les résultats sont très positifs. Pas de problème particulier de disponibilité, l’ensemble est stable. J’envisage donc de continuer dans cette direction en migrant davantage de services sur ma propre infrastructure.

C’est là que la question du matériel intervient. Mon Pi, très pratique pour de l’expérimentation limitée, montre quelques faiblesses sur des services plus gourmands en ressources (constaté sur Wallabag notamment). Pour être en mesure d’auto-héberger mes autres services, utiliser une machine plus puissante me semble tout indiqué.

J’ai identifié trois possibilités : utiliser un PI dernier modèle, passer à un mini PC type NUC, BRIX ou enfin, monter une configuration moi-même. Chaque choix a ses avantages et ses inconvénients. En faveur du Pi, je vois la faible consommation électrique et l’encombrement minimal. Un moins peut-être pour le stockage sur carte SD (il est néanmoins possible d’utiliser un disque dur classique). Le coût d’acquisition me semble être le plus faible des trois. Pour la solution médiane du barebone (NUC, BRIX, …)  : coût plus élevé avec nécessité d’acquérir HDD et RAM (type PC portable) en sus. Plus de puissance que le PI, mais plus de consommation électrique aussi. Troisième et dernière solution envisagée, construire une configuration. Comme pour le barebone, plus de puissance, plus de consommation et prix plus élevé, mais davantage de possibilité d’évolution.

La solution Pi 3 est attractive car très simple à mettre en place et ne nécessitant pas un investissement monétaire important. Je m’interroge encore sur la création d’une configuration sur mesure. Je dispose d’une machine vieillissante, vestige de mes premiers essais de serveur domestique, qui date d’une époque où le Raspberry Pi n’existait pas et où on pouvait aller acheter ses composants chez Surcouf. Le CPU est un Dual Core E3400 qui pourrait faire l’affaire. Le problème se situe plutôt du côté de la RAM, puisque la carte mère n’accepte que de la DDR2 800/667 MHz jusqu’à 4 GB total sur 2 slots. Il est heureusement encore possible de trouver ce type de RAM dans le commerce, mais le prix de la DDR2 reste plus élevé que celui de la DDR4 dernière génération, à capacité égale (en termes de mémoire, pas de fréquence).

Je vais donc me tourner vers une solution intermédiaire, en « recyclant » cette machine pour remplacer le Pi 1 utilisé jusqu’à présent. Je resterai sur 1 Go de RAM dans un premier temps et jetterai un coup d’œil du côté de l’occasion pour éventuellement passer à 4 Go à faible coût. De cette manière, je devrais être en mesure de migrer progressivement vers l’auto-hébergement de la majorité des services jusqu’à présent hébergé sur un serveur OVH. Si les performances s’avéraient trop faible, il serait alors possible d’envisager un changement de carte mère, processeur et mémoire RAM, et de réduire au passage la consommation électrique (en supposant que des progrès aient été réalisés dans le domaine de la gestion d’énergie ces dix dernières années).

Il restera néanmoins toujours la limitation du débit montant sur les lignes adsl, qui pourrait remettre en cause la migration de l’un ou l’autre des services. Nous verrons ceci à l’usage. Enfin, reste la question de ce site même, qui n’a pas vocation à être auto-hébergé pour le moment et qui sera donc migré vers un autre service.