Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier

Posté par Amaury Bouchard (site web personnel) le 13 août 2017 à 10:30. Édité par ZeroHeure, Davy Defaud et claudex. Modéré par bubar🦥. Licence CC By‑SA.

Étiquettes :

août

2017

Pour mes besoins personnels et professionnels, j’ai développé un script pour sauvegarder mes données (fichiers présents sur le disque local et bases de données MySQL) et les archiver sur Amazon S3 et Amazon Glacier.

Il est possible de choisir la fréquence de sauvegarde (jusque toutes les heures si nécessaire) et de définir une politique précise pour la purge des données. Il est ainsi possible d’avoir un comportement du type :

sauvegarde toutes les heures : les données sont enregistrées en local et envoyées sur Amazon S3 et Amazon Glacier ;
toutes les sauvegardes sont gardées en local pendant deux jours, puis on garde quatre sauvegardes par jour (une toutes les six heures) pendant cinq jours, puis une par jour pendant deux semaines, puis elles sont effacées ;
toutes les sauvegardes sont gardées sur Amazon S3 pendant deux semaines, puis on garde six sauvegardes par jour (une toutes les quatre heures) pendant deux semaines, puis deux par jour pendant un mois, puis elles sont effacées ;
toutes les données sont gardées sans limite de temps sur Amazon Glacier.

Le choix des services cloud d’Amazon se veut pragmatique. Amazon S3 est très utilisé pour stocker des données auxquelles on veut pouvoir accéder rapidement. Amazon Glacier est très pratique pour enregistrer des données sur le long terme pour un coût très bas.

Ce script propose une interface de configuration en ligne de commande qui se veut facile à utiliser. Les fichiers journaux se veulent aussi les plus lisibles possibles.

Exemple de configuration :

Exemple de fichier journal :

Le code a été placé sous la licence MIT (licence libre permissive).

Aller plus loin

Code source sur GitHub (566 clics)
Annonce sur mon blog (236 clics)

# Encryption

Posté par Amaury Bouchard (site web personnel) le 13 août 2017 à 15:44. Évalué à 5.

Je viens d'ajouter une fonctionnalité d'encryption. Les données peuvent maintenant être cryptées en utilisant OpenSSL (algorithme AES 256 bits), aussi bien pour les fichiers stockés en local que pour ceux enregistrés sur Amazon S3 et Amazon Glacier.

Il est possible d'utiliser une clé générée préalablement ou de fournir une passphrase.
- [^] # Re: Encryption
  
  Posté par freem le 14 août 2017 à 00:12. Évalué à 5.
  
  s/encryption/chiffrement/
  
  Oui je m'ennuies :)
  
  Sinon, pourquoi OpenSSL au lieu de LibreSSL? Si ma memoire est bonne le fork serait plus clean et, surtout, propose une API (non compatible celle-la, forcément) plus facile à utiliser pour un non-expert du chiffrement.
  - [^] # Re: Encryption
    
    Posté par Amaury Bouchard (site web personnel) le 14 août 2017 à 01:44. Évalué à 5.
    
    Effectivement, le mot «encrypter» existe en français, mais pas «encryption»…
    
    On reparlera de LibreSSL quand ce sera intégré dans les dépôts de toutes les principales distributions, hein. En attendant, l'utilisation d'OpenSSL ne pose strictement aucun problème. On peut faire plus simple, c'est vrai, mais dans le cadre qui concerne Arkiv (encrypter des données en utilisant une clé symétrique) il n'y a rien de compliqué, et c'est bien documenté dans le README.
    
    La question aurait plutôt pu être pourquoi OpenSSL plutôt que OpenPGP/GnuPG. La réponse : parce que je connais mieux.
# Information sur le volume cible

Posté par abriotde (site web personnel, Mastodon) le 14 août 2017 à 14:07. Évalué à 2.

Bonjour,

Merci pour cet outils. Je trouverais intéressant qu'il soit expliquer le volume cible et les contrepartie sur la page d'acceuil GitHub. Je n'ai pas regardé en détail mais j'ai l'impression que l'utilitaire est destiné à des bases de données de relativement faibles volume (mysqldump). En effet je n'ai pas l'impression qu'il soit question de partitionner les tables MySQL (nécessaire pour une purge de gros volume) et y a t'il un système de mise en pause / reprise des autres scripts (arrêt de la modification pour avoir une base cohérente).

Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
- [^] # Re: Information sur le volume cible
  
  Posté par Amaury Bouchard (site web personnel) le 14 août 2017 à 18:15. Évalué à 3.
  
  Merci pour les remerciements :)
  
  Je ne sais pas ce que tu veux dire quand tu parles de contrepartie. Il n'y a pas de limite au volume. C'est sûr que si tu as de grosses bases de données et/ou des fichiers volumineux, la sauvegarde risque de prendre du temps. Mais c'est difficile de faire autrement. Comme il est possible d'exécuter plusieurs instances d'Arkiv en parallèle, avec des fichiers de configuration différent, on peut imaginer faire des sauvegardes séparées pour que les données les plus légères soient archivées plus fréquemment.
  
  Le dump de la base se fait dans une transaction, donc il n'y a pas besoin de mettre quoi que ce soit en pause à la condition que les tables soient toutes en InnoDB. La chose est détaillée dans un article de mon blog.
  
  Ensuite, il est possible de mettre en place une stratégie de réplication maître-esclave, pour que la sauvegarde des bases se fasse sur un esclave (afin de ne pas impacter le serveur maître, que ce soit en consommation CPU ou mémoire). Il est aussi possible d'utiliser les logs binaires ; c'est alors une sauvegarde classique de fichier. Mais il vaut quand même mieux avoir un dump complet de temps en temps.
  
  Pour la question du partitionnement des tables, c'est quelque chose que je n'ai jamais vu mis en œuvre uniquement pour la sauvegarde (je l'ai déjà vu pour faire du sharding par exemple). Sur quel genre de volumétrie as-tu eu besoin de faire ça ?
  
  Les seules limites pour le moment concernent Amazon :
  - Les fichiers peuvent faire jusqu'à 5 TO sur Amazon S3 (source)
  - Les fichiers peuvent faire jusqu'à 40 TO sur Amazon Glacier (source)
  
  Je ferai peut-être une évolution pour découper les fichiers dont la taille est supérieure à ces limites. Je n'en ai personnellement pas le besoin, donc si ça peut être utile à quelqu'un, ce serait bien de me faire signe :)
- [^] # Re: Information sur le volume cible
  
  Posté par steph1978 le 16 août 2017 à 10:07. Évalué à 2.
  
  Je voulais poster un commentaire similaire. J'ai donc plussé.
  
  J'ai cherché le mécanisme de backup mysql encapsulée par Arkiv - avant de lire le commentaire - car c'est l'information la plus importante pour moi.
  
  L'utilisation de mysqldump est très structurantes pour les limitations de l'outil présenté et devrait être mentionnée dans la présentation.
  
  Autre réaction, j'aurai séparé le script de sauvegarde du script de création du fichier de configuration. Principalement pour des raisons de lisibilité et de maintenance. Mille lignes de bash, c'est pas simple…
  
  Ceci dit, l'effort d'intégration des toutes ses fonctions est appréciable. Merci pour le partage.
  - [^] # Re: Information sur le volume cible
    
    Posté par Amaury Bouchard (site web personnel) le 16 août 2017 à 14:33. Évalué à 1.
    
    Le code est découpé en fonctions et assez bien commenté, donc il est plutôt facile à maintenir. Je n'ai pas séparé le script en deux pour une bonne raison : En shell, il est impossible de savoir de manière sûre à 100% le chemin du script qui s'exécute (cf. http://mywiki.wooledge.org/BashFAQ/028). Du coup, il devient très compliqué d'inclure des fichiers sans imposer l'installation du programme dans une arborescence fixe (solution utilisée par backup-manager, par exemple). Je tiens à ce que le programme soit utilisable par n'importe quel utilisateur sans qu'il n'ait été d'abord installé par le root. Et il y a certaines parties du code qui sont mutualisées (notamment la gestion du formatage ANSI).
    
    Pour les défaut de mysqldump, est-ce que tu as des liens à ce sujet ? Comme je l'ai déjà dit dans un commentaire précédent, je n'ai jamais été face à une volumétrie telle que cet outil pouvait poser problème (et pourtant, j'ai fait pas mal de sauvegardes en production sur des bases assez conséquentes ces 15 dernières années).
    - [^] # Re: Information sur le volume cible
      
      Posté par steph1978 le 16 août 2017 à 15:45. Évalué à 2.
      mysqldump a des atouts :
      
      pas besoin d'arrêter la base ou de mettre en place des mécanisme complexe de snapshot
      
      format de dump interopérable et pérenne
      
      Mais de par son fonctionnement, il a des limites.
      
      monopolise une transaction en lecture tout le temps de la lecture des tables.
      
      doit générer du SQL ce qui est lent par rapport à une copie de fichier
      
      la restauration elle aussi est très longue comparée à une copie de fichier car le SQL doit être interprété.
      
      crée un fichier au moins aussi gros mais en pratique plutôt 2x plus gros que la base à sauvegarder car le SQL est plus verbeux que le binaire
      
      n'est pas incrémentale, donc toute la base à scanner et tout la volumétrie à stocker à chaque sauvegarde
      
      Pour une base un peu conséquente et sollicitée, il devient rapidement impossible de s'en servir pour un sauvegarde horaire. la prochaine horaire sera lancée avant même que la précédente ne soit finie. et le coût en S3, bien que bon marché, est loin d'être optimisé.
      
      Les moyens de contournement de ces limitations seraient d'utiliser les binlogs pour l'incrémental et de la déduplication pour la full, le tout sur un slave.
      
      C'est ce que suggère la documentation mysql d'ailleurs (ils ne parlent pas de déduplication mais de binlogs et de slave).
    - [^] # Re: Information sur le volume cible
      
      Posté par shbrol le 16 août 2017 à 20:52. Évalué à 1.
      
      En shell, il est impossible de savoir de manière sûre à 100% le chemin du script qui s'exécute (cf. http://mywiki.wooledge.org/BashFAQ/028).
      
      Merci pour le lien !
    - [^] # Re: Information sur le volume cible
      
      Posté par bunam le 29 août 2017 à 23:44. Évalué à 1.
      J'utilise ceci au début de mes scripts principaux placé dans le path :
      
      function echoer() { echo "$@" 1>&2 ; } function die() { echoer "$@" ; exit 1 ;} command -v readlink &> /dev/null if [ "$?" -eq "0" ] ; then #shellcheck disable=SC2155 export curdir="$( cd "$( dirname "$(readlink "${BASH_SOURCE[0]}" || echo "${BASH_SOURCE[0]}" )" )" && pwd )" else #shellcheck disable=SC2155 export curdir="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" fi if [ -s "${curdir}/../lib/px-lib" ] ; then source "${curdir}/../lib/px-lib" if [ ! "$?" -eq "0" ] ; then die "Erreur de chargement du fichier de lib : ${curdir}/../lib/px-lib" fi else die "Impossible de trouver le fichier de la lib : ${curdir}/../lib/px-lib" fi
      
      et dans la px-lib je peux charger d'autre truc
      
      Et ça marche sous MacOS / CentOS / Debian / cmder sous Windows avec des chemins ~~à la con~~ par normés.
      
      sinon une autre méthode avec recherche du fichier px-lib dans different dossiers éventuels :
      
      function echoer() { echo "$@" 1>&2 ; } function die() { echoer "$@" ; exit 1 ;} function px_search_file() { local find=$1 ; local n=$# ; for ((i=2;i <= n;i++)) { local path=${!i}/$find ; if [ -e "${path}" ]; then echo "${path}"; return 0; fi } ; return 1 ; } PX_LIB=$(px_search_file "lib/px-lib" "$PX_LIB_PATH_SEARCH" "/opt/pxtools" "/c/dev/Utils/pxtools/bin/px-tools" "/c/DEV/pxtools" "/Users/Shared/Documents/sources/pxtools") || die "Erreur : impossible de charger la librairie px-lib"
      
      J'espère ne pas finir séché sous un faux plafond ;) (private joke)
# Petite suggestion

Posté par HanX (site web personnel) le 15 août 2017 à 09:25. Évalué à 1.

Hello,

Tu utilises mysqldump, cependant cet outil pose des soucis avec des grosses BDD. Est-ce que tu pourrais prendre en charge percona xtrabackup ?

A+
- [^] # Re: Petite suggestion
  
  Posté par Amaury Bouchard (site web personnel) le 16 août 2017 à 14:43. Évalué à 1.
  
  C'est envisageable.
  
  Je te pose la même question qu'aux autres qui m'ont fait une demande similaire : Est-ce que tu aurais des liens qui documenteraient les limitations de mysqldump ? Ça m'intéresse évidemment.
  - [^] # Re: Petite suggestion
    
    Posté par Benoît Sibaud (site web personnel) le 16 août 2017 à 15:15. Évalué à 4.
    
    Principalement la dégradation de performances et le verrouillage de tables pendant le dump. Voir par exemple https://severalnines.com/blog/mysqldump-or-percona-xtrabackup-backup-strategies-mysql-galera-cluster
    - [^] # Re: Petite suggestion
      
      Posté par Amaury Bouchard (site web personnel) le 16 août 2017 à 18:10. Évalué à 1.
      
      Non, justement. Comme je l'ai indiqué dans un précédent commentaire, j'ai écrit un article de blog sur la question. Il est possible de ne pas verrouiller les tables, et de faire le dump dans une transaction pour être sûr de ne pas récupérer des données qui ont changé pendant la durée du dump. C'est d'ailleurs expliqué dans le lien que tu as fourni.
      
      Et pour ce qui est des caches MySQL qui se retrouvent à être utilisés pour mysqldump au lieu d'être remplis de données utiles pour les traitements "normaux" de la base, la solution est de mettre en place une réplication maître-esclave et de faire les sauvegardes sur l'esclave.
      
      Mais je comprends aussi que s'il existe un outil plus performant, ce serait idiot de ne pas le supporter :)
      
      Toutefois ce serait une erreur de ne pas supporter mysqldump, qui a l'avantage d'être quasi-toujours là. Et accessoirement, puisque quelqu'un comparaît avec Backup-Manager, il faut bien dire que lui aussi passe par mysqldump (oui, je sais que backup-manager peut sauvegarder les données de n'importe quel programme en passant par un “pipe”, mais ce n'est plus du «out-of-the-box»).
      - [^] # Re: Petite suggestion
        
        Posté par kna le 17 août 2017 à 12:06. Évalué à 2.
        
        Le --single-transaction, ça fonctionne uniquement lorsque tu est en full-InnoDB. Sinon, ton dump ne va pas être consistent.
        
        Mais le gros problème des dumps, comme dit plus haut, c'est que c'est très lent à réimporter. Sur une grosse base, le temps de restauration se compte en jours !
        Une sauvegarde physique (xtrabackup) est beaucoup plus rapide à restaurer. Ça n'empêche pas d'avoir une sauvegarde logique (mysqldump ou mydumper) en plus pour la souplesse que ça procure (backup par base ou par table notamment).
        
        [^] # Re: Petite suggestion
        
        Posté par Amaury Bouchard (site web personnel) le 17 août 2017 à 16:28. Évalué à 1.
        
        Le --single-transaction, ça fonctionne uniquement lorsque tu est en full-InnoDB. Sinon, ton dump ne va pas être consistent.
        
        Oui, bien sûr. Tu as encore des tables en MyISAM, toi ? Quel intérêt ?
        
        Bon, je vais regarder tout ça de près. Merci à tous pour vos conseils et liens.
        
        Comme je l'ai déjà dit, le but reste quand même de garder un code simple et clair, pas de faire un machine énorme qui répond à tous les besoins. L'utilisation de mysqldump est facile (je pense que toutes les distribs l'installent dès qu'on installe un client MySQL), c'est pour ça que je l'ai ajoutée (et aussi parce que − comme on me l'a fait remarquer − Arkiv est en concurrence avec Backup-Manager, qui gère mysqldump).
        
        Mais je comprends bien l'intérêt :)
        
        Petites question à mon tour :
        1. Comment faites-vous vos sauvegardes actuellement ?
        2. Est-ce que Arkiv vous serait utile, et n'y a-t-il vraiment que la sauvegarde par xtrabackup qui manque ? (et dans ce cas, pourquoi ne pas commencer par lancer xtrabackup avant Arkiv dans la crontab ?)
        
        Merci
      - [^] # Re: Petite suggestion
        
        Posté par HanX (site web personnel) le 19 août 2017 à 00:20. Évalué à 0.
        
        J'ai juste fait une suggestion de supporter en plus un autre format de sauvegarde. Outre les divers problèmes potentiels de lock que tu expliques bien, le gros du soucis est la restauration avec un très gros dump (plusieurs heures n'est pas rare).
        
        Percona Xtrabackup, permet de sauvegarder efficacement, mettre en pause si la charge est trop élevé, backup incrémental… pour ma part, mysqldump est un bon outil mais terriblement archaïque.
# backup-manager

Posté par martinclic le 15 août 2017 à 19:56. Évalué à 2.

Bonjour,

J'utilise avec satisfaction backup-manager depuis plusieurs années, qui répond pile à ce besoin.
(dispo dans dans les dépôts en ce qui concerne debian et ubuntu, et je crois aussi dans d'autres distributions).

Si tu connais, pourrais tu m'éclairer sur d'éventuels avantages de ton programme ?
- [^] # Re: backup-manager
  
  Posté par Amaury Bouchard (site web personnel) le 16 août 2017 à 14:13. Évalué à 3.
  
  Comme je le dis sur mon article de blog (en lien dans la dépêche), j'ai utilisé backup-manager pendant les 10 dernières années grosso modo.
  
  Ce que Arkiv fait et que backup-manager ne fait pas :
  - Possibilité de choisir la fréquence de sauvegarde, que ce soit plusieurs fois par jour (jusqu'à toutes les heures) ou pas tous les jours, alors que backup-manager est fait pour sauvegarder une fois par jour uniquement.
  - Peut archiver les données à long-terme sur Amazon Glacier (en plus de les archiver à moyen-terme sur Amazon S3, comme backup-manager).
  - Gère des politiques de purge complexes (cf. l'exemple donné dans la dépêche), alors que backup-manager efface tous les fichiers après un certain délai (et que en local, pas sur Amazon S3).
  - Aide à la création du fichier de configuration.
  - Fichiers de logs plus faciles à lire (c'est subjectif, je sais, mais un effort a été fait là-dessus).
  
  Je ne sais pas pour les toutes dernières version de backup-manager, mais celle que j'utilisais n'était pas compatible avec les datacenters Amazon les plus récents (celui de Londres par exemple), qui ne sont pas compatibles avec les anciennes versions de l'API.
- [^] # Re: backup-manager
  
  Posté par Amaury Bouchard (site web personnel) le 16 août 2017 à 14:58. Évalué à 3.
  
  Et pour être complet :
  - Backup-manager peut sauvegarder des fichiers de manière incrémentale, avec que Arkiv fait toujours des sauvegardes complètes. [1]
  - Backup-manager peut sauvegarder spécifiquement les données de serveurs Subversion ou celles de programmes qui sont "pipés".
  - Backup-manager est capable d'envoyer les sauvegardes par SCP, FTP ou rsync, et peut aussi graver des CD/DVD. Arkiv se contente d'Amazon S3 et Amazon Glacier.
  - Backup-manager peut encrypter les données avec GPG, alors que Arkiv utilise OpenSSL.
  
  [1] : C'est un choix de ma part. Je préfère avoir des sauvegardes complètes car elles sont plus faciles à restaurer (une seule archive à déployer, plutôt que de déployer la dernière archive complète plus toutes les archives incrémentales sauvegardées depuis). Ça peut évidemment faire stocker plus de données, mais avec une gestion fine des purges − comme le permet Skriv − je pense qu'on s'y retrouve largement.
  - [^] # Re: backup-manager
    
    Posté par martinclic le 16 août 2017 à 18:44. Évalué à 0.
    
    merci de cette réponse exhaustive !
# Support de xtrabackup

Posté par Amaury Bouchard (site web personnel) le 30 août 2017 à 02:48. Évalué à 2.

Suite aux demandes et remarques en commentaire, Arkiv supporte maintenant la sauvegarde binaire de bases de données MySQL par xtrabackup. Il est possible de configurer des sauvegardes complètes et des sauvegardes incrémentales.

N'hésitez pas à tester et à me faire des retours via la buglist ou par email.

PS : Plus anecdotique, j'ai aussi ajouté le support de syslog.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.