Hello
lors de conversation précédentes, j'ai compris que cette question pouvait être un sujet.
J'ai eu en 20ans plusieurs applis web d'asso en gestion avec quelques dizaines ou centaines d'acteurs et divers serveurs de fichiers dans le cloud ou onpremise, proxy, firewall, samba, etc.
Je suis resté très classique et très basique sur cette question, sachant que le use case majeur visé, c'est
savoir remettre l'appli ou le service sur pied au plus vite quand tout a brulé, eventuellement par quelqu'un d'autre et sans doc, sans licence, sans logiciel spécifique ...
Mes 2 CLI fétiches : pour backuper de manière exaustive tout le contenu du serveur mysql/mariadb
mysqldump -u root --all-databases | gzip > /BKP/MYSQLDUMP$TIMESTAMP.sql.gz
On suppose que le paswd root est dans ~/.my.cnf . Des options peuvent éventuellement geler les tables quand le dump passe dessus (c'est ce que j'ai compris).
Pour restaurer , éventuellement sur une machine neuve (ca m'est souvent arrivé surtout après un dist-upgrade):
gzip -d < /BKP/MYSQLDUMP$TIMESTAMP.sql.gz | mysql
Le format mysql est en clair, assez facile à comprendre, et à adapter le cas échéant quand on veut faire de la restauration partielle.
Interet: la production est faiblement impactée par ce bkp .
(La récupération du contenu de /var/lib/mysql n'est pas très sure...)
- Pour ce qui est du rootfs et des autres FS :
cd /
find -xdev | cpio -o |gzip > /BKP/$hostname-rootfs-$TIMESTAMP.cpio.gz
Là aussi , la prod n'est pas impactée.
Pour restaurer (là aussi c'est un sport fréquent chez moi ...) :
cd /RESTO
gzip -d < $hostname-rootfs-$TIMESTAMP.cpio.gz | cpio -idm
J'aime le cpio car :
- il est historique et très répandu sur tous les unix et pas seulement
- il est très facile de filtrer entre le "find" et le "cpio" en insérant un "|egrep -v -e 'xxx'| " par exemple pour éviter d'entrer dans le backup des catégories non désirées de fichiers
- il respecte les symlinks, les hardlinks, les fifos, les dev... les métadonnées à la Unix. Bref 100% compatible avec les besoins de bkp du rootfs.
Je n'ai pas exploré les technos snapshots faute de temps et au passage à d'autres sujet. La taille des disques aujourd'hui peut orienter vers ces principes. Mais la fragmentation en VM ou en containers des architectures peut orienter en sens inverse.... Débat à ouvrir ...
Sur des sites type Nextcloud, la question est à l'étude ... .
Pratiques salutaires sur LAMP : le backup.
Re: Pratiques salutaires sur LAMP : le backup.
Bonjour,
Et merci pour le sujet, nous avons tous le me problème à traiter et nous y allons de nos solution basées sur les outils open source du SGBD, moi le premier
J'y suis donc allé de mon rôle Ansible pour sauvegarder mes bases (dont celle du forum que vous lisez
Le rôle est disponible dans mon [codehttps://github.com/wbonnet/]github[/code] (licence Apache) et se nome dft_sysop_myqldump.
Il permet de faire automatiquement des mysqldump de une ou toutes les bases vers des fichiers différents.Le rôle permet de manipuler la crontab, compresser et horodater les fichiers.
Tous les paramètres sont configurables dans l'inventaire. Voici un exemple :
La doc qui détaille des champs a pas encore ete pousse vers github. Je peux accélérer si vous demandez
. Cependant les paramètres sont assez explicites ce sont ceux nomes dans le man de crontab et mysqldump. Original non? 
La question suivante est comment on recupères les sauvegardes ? et bien il a aussi un role pour cela, dft-sysop-rsync
@+W.
Et merci pour le sujet, nous avons tous le me problème à traiter et nous y allons de nos solution basées sur les outils open source du SGBD, moi le premier

J'y suis donc allé de mon rôle Ansible pour sauvegarder mes bases (dont celle du forum que vous lisez

Le rôle est disponible dans mon [codehttps://github.com/wbonnet/]github[/code] (licence Apache) et se nome dft_sysop_myqldump.
Il permet de faire automatiquement des mysqldump de une ou toutes les bases vers des fichiers différents.Le rôle permet de manipuler la crontab, compresser et horodater les fichiers.
Tous les paramètres sont configurables dans l'inventaire. Voici un exemple :
Code: Select all
mariadb_servers:
hosts:
dbserver-01:
# configure mysqldump backup of MariaDB databases running on this host
dft_sysop_mysqldump:
password:
user: root
archive_path: /var/backups/armwizard/sql
# tru pour faire un fichier de sauvegarde contenant toutes les bases, il n'est pas forcement utile defaaire cela en plus des sauvegardes individuelles, [i][b]"c'est vous qui voyez"[/b][/i] :lol:
all_databases: True
append_timestamp: True
timestamp_format: "%Y%m%d"
filename: alldb_tim-01
compress_archive: True
compress_tool: bzip2
compress_options: ""
# sauvegarde individuelle de chaque basen une entree YAML dans le liste par base a sauvegarder
databases_to_dump:
- name: my_databasename
password:
user: root
# chemin vers le repertoire de sauvegarde
archive_path: /var/backups/armwizard/sql
append_timestamp: True
filename: db_phpbb
compress_archive: True
compress_tool: bzip2
compress_options: ""
add_cronjob: True
crontab_entry:
description: "create daily mysqldump backup of database used for forum.armwizard.org"
month: "*"
weekday: "*"
day: "*"
hour: "17"
minute: "12"
username: root
La doc qui détaille des champs a pas encore ete pousse vers github. Je peux accélérer si vous demandez


La question suivante est comment on recupères les sauvegardes ? et bien il a aussi un role pour cela, dft-sysop-rsync

@+W.