Don't blame it on the Lexpage !
—
Jackson five
Discussions
Backups pour Lexpage
Hello,
Vous le savez sans doute déjà parce que j'en avais déjà brièvement parlé il y a un bon moment, mais des backups du Lexpage sont générés quotidiennement et sont stockés pendant 14 jours via Dropbox. Jusqu'à présent, la solution est plutôt simple :
1. Un dump de la db et un clone des fichiers est réalisé chaque jour;
2. Logrotate s'occupe de nommer ça comme un grand en virant les "vieux" backups;
3. Le tout est déplacé dans un répertoire synchronisé via Dropbox.
De temps en temps, je me rappelle que tout ça, ça peut casser du jour au lendemain, alors je vais vérifier manuellement sur Dropbox que les fichiers sont bien présents. Pour la postérité, notez que je découvre aujourd'hui (juillet 2019) que le dernier backup synchronisé date de septembre 2018. Oui, j'ai honte...
La raison est "simple" : la version installée de Dropbox (le démon dropboxd) est "trop vieille" pour fonctionner encore (aucun message dans les logs ne l'indique, cependant). Du coup, la solution semble simple également : mettre à jour !
Mais c'est là que ça se gâte : la plus ancienne version fonctionnelle (comprendre : qui est acceptée par Dropbox) nécessite au moins glibc 2.18 pour fonctionner (et les plus récentes, glibc 2.19). A priori, ce n'est pas un souci, sauf que je tourne sous Centos7, et que la dernière glibc disponible est... roulements de tambours: glibc 2.17 ! Et pas moyen "safe" d'aller plus loin via le gestionnaire de paquets.
On entame donc sa patience, et on regarde les alternatives possibles : installer une version récente de glibc ailleurs sur le système, et espérer que ça ne casse pas tout en l'isolant quelque part. Le problème, c'est que les versions "récentes" de glibc nécessitent des versions récentes de ld, make, bison, etc. pour être compilées. Et ces différents trucs nécessitent.... glibc, vous l'avez compris Installer une version de glibc en parallèle de la version système étant déjà "potentiellement dangereux", en installer plusieurs, c'est sans doute un peu de la folie 
J'ai donc désactivé/désinstallé complètement le backup via Dropbox, mais ça signifie que pour l'instant, il n'y a plus aucun backup exporté vers "l'extérieur" (comprendre : ailleurs que sur le VPS). Or, de mémoire, OVH n'inclut aucun service automatique de "snapshots" ou de backups pour les VPS de cette gamme (et activer l'option double grosso-modo le prix du VPS).
J'en appelle donc à vos bonnes idées : quelles alternatives pourriez-vous me proposer pour ces backups ? Il doit y avoir un "minimum" de sécurité parce que la db contient (notamment) vos passwords (salés et chiffrés, mais il vaut mieux être prudent !). En terme de besoin, les backups J-1, J-2, J-3, J-7 et J-14 représentent environ 450mo de données, qu'on peut ramener à environ 100mo si je ne backup pas les stats.
Vous le savez sans doute déjà parce que j'en avais déjà brièvement parlé il y a un bon moment, mais des backups du Lexpage sont générés quotidiennement et sont stockés pendant 14 jours via Dropbox. Jusqu'à présent, la solution est plutôt simple :
1. Un dump de la db et un clone des fichiers est réalisé chaque jour;
2. Logrotate s'occupe de nommer ça comme un grand en virant les "vieux" backups;
3. Le tout est déplacé dans un répertoire synchronisé via Dropbox.
De temps en temps, je me rappelle que tout ça, ça peut casser du jour au lendemain, alors je vais vérifier manuellement sur Dropbox que les fichiers sont bien présents. Pour la postérité, notez que je découvre aujourd'hui (juillet 2019) que le dernier backup synchronisé date de septembre 2018. Oui, j'ai honte...
La raison est "simple" : la version installée de Dropbox (le démon dropboxd) est "trop vieille" pour fonctionner encore (aucun message dans les logs ne l'indique, cependant). Du coup, la solution semble simple également : mettre à jour !
Mais c'est là que ça se gâte : la plus ancienne version fonctionnelle (comprendre : qui est acceptée par Dropbox) nécessite au moins glibc 2.18 pour fonctionner (et les plus récentes, glibc 2.19). A priori, ce n'est pas un souci, sauf que je tourne sous Centos7, et que la dernière glibc disponible est... roulements de tambours: glibc 2.17 ! Et pas moyen "safe" d'aller plus loin via le gestionnaire de paquets.
On entame donc sa patience, et on regarde les alternatives possibles : installer une version récente de glibc ailleurs sur le système, et espérer que ça ne casse pas tout en l'isolant quelque part. Le problème, c'est que les versions "récentes" de glibc nécessitent des versions récentes de ld, make, bison, etc. pour être compilées. Et ces différents trucs nécessitent.... glibc, vous l'avez compris
Installer une version de glibc en parallèle de la version système étant déjà "potentiellement dangereux", en installer plusieurs, c'est sans doute un peu de la folie J'ai donc désactivé/désinstallé complètement le backup via Dropbox, mais ça signifie que pour l'instant, il n'y a plus aucun backup exporté vers "l'extérieur" (comprendre : ailleurs que sur le VPS). Or, de mémoire, OVH n'inclut aucun service automatique de "snapshots" ou de backups pour les VPS de cette gamme (et activer l'option double grosso-modo le prix du VPS).
J'en appelle donc à vos bonnes idées : quelles alternatives pourriez-vous me proposer pour ces backups ? Il doit y avoir un "minimum" de sécurité parce que la db contient (notamment) vos passwords (salés et chiffrés, mais il vaut mieux être prudent !). En terme de besoin, les backups J-1, J-2, J-3, J-7 et J-14 représentent environ 450mo de données, qu'on peut ramener à environ 100mo si je ne backup pas les stats.
Aaah oui, pas bête, j'ai un Rasp qui me sert de NAS (et que je n'utilise en réalité jamais ) qui pourrait faire le job.
) qui pourrait faire le job.
yaugCela m'arrive mais ne t'habitues pas quand même
TchouOuais, c'était ma proposition également, sous réserve que tu aie une IP fixe (?).Je lance le rsync depuis mon rasp, donc le souci de l'IP fixe n'en est pas un (le VPS a une IP fixe, pas de souci de ce coté
TchouSinon, tu ne peux pas updater l'OS ?Je préfère ne pas prendre le risque, car je m'attends à ce que beaucoup de choses ne se passent pas correctement, et je n'ai actuellement pas le temps de passer une demie journée (voire une journée complète) pour réinstaller le VPS au cas où "ça foire"
