Publié initialement à : https://korben.info/sauvegarder-serveur-linux-s3.html
Dans la vie, y’a 2 choses vraiment importantes. 1/ L’amour 2/ Faire des sauvegardes Alors on va voir aujourd’hui comment mettre en place une sauvegarde d’un Linux avec upload vers Amazon S3 (mais vous pourrez aussi faire de l’upload vers FTP ou un autre serveur via SSH). Et pour cela, on va utiliser Backup Manager. Le site…
ça me semble une solution très compliqué, il n’est pas plus rapide d’écrire les 5-6 lignes qui vont bien ? :
mount /mnt/amazon/backup
mysqldump … | bzip > /mnt/amazon/backup/sql.bz
tar -cvf … | bzip
if error mail
umount /mnt/amazon/backup
Donc maintenant que la deuxième chose la plus importante dans la vie a été traité, à quand un article sur l’amour? 
Juste un petit “tric”, faire une sauvegarde à 02h00 ou 3h00 c’est pas terrible (c’est pas un drame non plus)
il y des jours où ça se passera mal (les 2 changements d’heure)
Il y a probablement un jour ou tu ne feras pas de sauvegarde et un autre ou tu en fera 2 
Mieux vaut préférer 01h59 ou 03h01 (et ne mettre aucun script dans l’intervalle de 02h00 à 03h00…)
C’est pas incrémental, pas chiffré, pas de vérification de l’intégrité de tes données en faisant ça, c’est pas daté (c’est que un $(date -I) à ajouter mais bon), c’est difficile de restaurer par la suite.
Perso j’ai une préférence pour duplicity-backup.sh (https://github.com/zertrin/duplicity-backup.sh)
Oula, ca parait bien compliqué cette affaire… des srcipts par ci et par là… Bon. perso j’utilise backuppc, ca marche tres bien, ca s’installe en moins de deux, y’a pas moultes scripts a lancer, c’est ptet pas ultra sécurisé au niveau de l’interface web (oui oui interface web) mais au moins ca fait le job de maniere centralisée.
windows et unix , Incremental et full backup.
Certes on n’est plus du tout dans l’optique d’une solution vers Amazon S3 dans ce cas.
C’est un peu mon propos en fait :
Faire de l’incrémental n’a d’intérêt qu’en parallèle d’un backup complet moins régulier.
Chiffré : pourquoi pas par contre attention à ne pas backupé la clé chiffrée avec elle même 
Vérifier l’intégrité, est inutile sur un backup full
Bref ce que je veux dire c’est que ces utilitaires tout fait tu ne sais pas trop comment ça marche, tu n’es pas à l’abri qu’un matin une màj foire la compatibilité, c’est inutilement compliqué (gérer du FTP, du SSH 40 versions de cloud résultat pour duplicity-backup hors dépendance +1000 lignes de scripts, 450lignes de fichier config)
En écrivant soit même la ligne de code:
- on sait ce qui est fait / comment ça marche
- on réfléchit (dois-je faire de l’incrémental ? dois-je compresser ? dois-je chiffrer ? comment backuper la clé ?)
- on apprend le bash
- on fait un truc plus simple (à maintenir, ou en cas de pépins)
Mettre ces utilitaires dans les mains d’un newby, tu peux être certains qu’il va activer toutes les options, et se retrouver avec un backup inutilisable (“J’ai un backup incrémentale chiffré, la clé et dans l’archive et en plus j’ai changé ma clé SSH il y’a 6mois, comment je fais pour récupérer mon disque-dur qui vient de crasher ? Je n’éai pas d’autre backup c’est urgent !”)
Je persiste remplir ça :
https://github.com/zertrin/duplicity-backup.sh/blob/dev/duplicity-backup.conf.example me semble bien plus compliqué qu’apprendre à chaîner 4 instructions en bash.
Après il y’a sans doute un pb de point de vue:
- un sysadmin qui maîtrise le backup préférera un truc tout fait pour gagner du temps.
- un hobbist aura peut-être envie de enfin comprendre ce que signifie ces “tar xjf” copier/coller sur le net depuis des années.