TaskFreak Stratégie Backup : Différence entre versions
m |
(Aucune différence)
|
Version actuelle en date du 15 mai 2018 à 12:38
L'application TaskFreak utilise une base de données et des espaces de stockage, dont une sauvegarde est nécessaire. Cet article présente la mise en place d'une stratégie de backup, sous Ubuntu, permettant de réaliser:
- 1 sauvegarde quotidienne de la base de données.
- Export des sauvegardes vers un serveur "externe" via FTP.
- Conservation des trois dernières sauvegardes complètes, et des incrémentales.
La synchronisation des sauvegardes s'effectue à l'aide de l'outil de backup Duplicity. Le fait d'externaliser les sauvegardes apporte une garantie supplémentaire. En effet, si le serveur venait à être en panne, les sauvegardes de TaskFreak resteront disponibles.
La base de données MySQL est sauvegardée à l'aide de l'outil AutoMySQLBackup. Pour cela, un compte de sauvegarde est utilisé pour accéder à la base de données en lecture seule.
Sommaire
Votre avis
Nobody voted on this yet
|
|
Objectif
L'installation faite sous Ubuntu met en place différents répertoires / fichiers:
- Répertoire
/var/opt/taskfreak-*
: Contient les instances installées, ainsi que les extensions mises en place. - Lien
/var/opt/taskfreak
: Lien vers l'instance utilisée. - Fichier
/etc/apache2/sites-available/default.conf
: Contient la déclaration de la publication sous Apache. - Lien
/etc/apache2/sites-enabled/000-default.conf
: Lien pour la prise en compte des configurations Apache.
Sous Ubuntu, il existe le répertoire /var/backups
, utilisé par aptitude, dpkg, OpenLDAP ... Cependant, il ne sera pas utilisé dans le cadre de cet article, pour ne pas engendrer d'éventuels effets de bord.
Tous les scripts et données seront stockés dans un nouveau répertoire /var/opt/backups
(pour l'ensemble des stratégies) et plus particulièrement dans le répertoire /var/opt/backups/taskfreak
pour taskfreak.
Concernant les logs, elles seront toutes placées dans le répertoire /var/log/backups
.
#sudo mkdir -p /var/opt/backups/taskfreak #sudo chmod 740 /var/opt/backups/taskfreak #sudo chown root:root /var/opt/backups/taskfreak #sudo mkdir /var/log/backups
Sauvegardes
La base de données est sauvegardées à l'aide de AutoMySQLBackup. Cette dernière application permet d'exécuter des exécutions après export, ce qui est utilisé pour déclencher la sauvegarde des exports, des installations, à l'aide de l'outil Duplicity.
Source
La configuration taskfreak_automysqlbackup.conf
est mise en place, avec des sécurités autorisant uniquement le compte root
à le modifier, dans le répertoire /var/opt/backups/taskfreak
avec le code suivant:
#version=3.0_rc2
# DONT'T REMOVE THE PREVIOUS VERSION LINE!
#
# Uncomment to change the default values (shown after =)
# WARNING:
# This is not true for UMASK, CONFIG_prebackup and CONFIG_postbackup!!!
#
# Default values are stored in the script itself. Declarations in
# /etc/automysqlbackup/automysqlbackup.conf will overwrite them. The
# declarations in here will supersede all other.
# Edit $PATH if mysql and mysqldump are not located in /usr/local/bin:/usr/bin:/bin:/usr/local/mysql/bin
#PATH=${PATH}:FULL_PATH_TO_YOUR_DIR_CONTAINING_MYSQL:FULL_PATH_TO_YOUR_DIR_CONTAINING_MYSQLDUMP
# Basic Settings
# Username to access the MySQL server e.g. dbuser
CONFIG_mysql_dump_username='backup'
# Password to access the MySQL server e.g. password
CONFIG_mysql_dump_password='<BACKUP_PASSWORD>'
# Host name (or IP address) of MySQL server e.g localhost
CONFIG_mysql_dump_host='localhost'
# "Friendly" host name of MySQL server to be used in email log
# if unset or empty (default) will use CONFIG_mysql_dump_host instead
#CONFIG_mysql_dump_host_friendly=''
# Backup directory location e.g /backups
CONFIG_backup_dir='/var/opt/backups/taskfreak/db'
# This is practically a moot point, since there is a fallback to the compression
# functions without multicore support in the case that the multicore versions aren't
# present in the system. Of course, if you have the latter installed, but don't want
# to use them, just choose no here.
# pigz -> gzip
# pbzip2 -> bzip2
CONFIG_multicore='yes'
# Number of threads (= occupied cores) you want to use. You should - for the sake
# of the stability of your system - not choose more than (#number of cores - 1).
# Especially if the script is run in background by cron and the rest of your system
# has already heavy load, setting this too high, might crash your system. Assuming
# all systems have at least some sort of HyperThreading, the default is 2 threads.
# If you wish to let pigz and pbzip2 autodetect or use their standards, set it to
# 'auto'.
CONFIG_multicore_threads=2
# Databases to backup
# List of databases for Daily/Weekly Backup e.g. ( 'DB1' 'DB2' 'DB3' ... )
# set to (), i.e. empty, if you want to backup all databases
CONFIG_db_names=( 'taskfreak' )
# You can use
#declare -a MDBNAMES=( "${DBNAMES[@]}" 'added entry1' 'added entry2' ... )
# INSTEAD to copy the contents of $DBNAMES and add further entries (optional).
# List of databases for Monthly Backups.
# set to (), i.e. empty, if you want to backup all databases
CONFIG_db_month_names=( 'taskfreak' )
# List of DBNAMES to EXLUCDE if DBNAMES is empty, i.e. ().
#CONFIG_db_exclude=( 'information_schema' )
# List of tables to exclude, in the form db_name.table_name
# You may use wildcards for the table names, i.e. 'mydb.a*' selects all tables starting with an 'a'.
# However we only offer the wildcard '*', matching everything that could appear, which translates to the
# '%' wildcard in mysql.
#CONFIG_table_exclude=()
# Advanced Settings
# Rotation Settings
# Which day do you want monthly backups? (01 to 31)
# If the chosen day is greater than the last day of the month, it will be done
# on the last day of the month.
# Set to 0 to disable monthly backups.
CONFIG_do_monthly="0"
# Which day do you want weekly backups? (1 to 7 where 1 is Monday)
# Set to 0 to disable weekly backups.
CONFIG_do_weekly="0"
# Set rotation of daily backups. VALUE*24hours
# If you want to keep only today's backups, you could choose 1, i.e. everything older than 24hours will be removed.
CONFIG_rotation_daily=1
# Set rotation for weekly backups. VALUE*24hours
#CONFIG_rotation_weekly=35
# Set rotation for monthly backups. VALUE*24hours
#CONFIG_rotation_monthly=150
# Server Connection Settings
# Set the port for the mysql connection
CONFIG_mysql_dump_port=3306
# Compress communications between backup server and MySQL server?
#CONFIG_mysql_dump_commcomp='no'
# Use ssl encryption with mysqldump?
#CONFIG_mysql_dump_usessl='yes'
# For connections to localhost. Sometimes the Unix socket file must be specified.
#CONFIG_mysql_dump_socket=''
# The maximum size of the buffer for client/server communication. e.g. 16MB (maximum is 1GB)
#CONFIG_mysql_dump_max_allowed_packet=''
# This option sends a START TRANSACTION SQL statement to the server before dumping data. It is useful only with
# transactional tables such as InnoDB, because then it dumps the consistent state of the database at the time
# when BEGIN was issued without blocking any applications.
#
# When using this option, you should keep in mind that only InnoDB tables are dumped in a consistent state. For
# example, any MyISAM or MEMORY tables dumped while using this option may still change state.
#
# While a --single-transaction dump is in process, to ensure a valid dump file (correct table contents and
# binary log coordinates), no other connection should use the following statements: ALTER TABLE, CREATE TABLE,
# DROP TABLE, RENAME TABLE, TRUNCATE TABLE. A consistent read is not isolated from those statements, so use of
# them on a table to be dumped can cause the SELECT that is performed by mysqldump to retrieve the table
# contents to obtain incorrect contents or fail.
#CONFIG_mysql_dump_single_transaction='no'
# http://dev.mysql.com/doc/refman/5.0/en/mysqldump.html#option_mysqldump_master-data
# --master-data[=value]
# Use this option to dump a master replication server to produce a dump file that can be used to set up another
# server as a slave of the master. It causes the dump output to include a CHANGE MASTER TO statement that indicates
# the binary log coordinates (file name and position) of the dumped server. These are the master server coordinates
# from which the slave should start replicating after you load the dump file into the slave.
#
# If the option value is 2, the CHANGE MASTER TO statement is written as an SQL comment, and thus is informative only;
# it has no effect when the dump file is reloaded. If the option value is 1, the statement is not written as a comment
# and takes effect when the dump file is reloaded. If no option value is specified, the default value is 1.
#
# This option requires the RELOAD privilege and the binary log must be enabled.
#
# The --master-data option automatically turns off --lock-tables. It also turns on --lock-all-tables, unless
# --single-transaction also is specified, in which case, a global read lock is acquired only for a short time at the
# beginning of the dump (see the description for --single-transaction). In all cases, any action on logs happens at
# the exact moment of the dump.
# ==================================================================================================================
# possible values are 1 and 2, which correspond with the values from mysqldump
# VARIABLE= , i.e. no value, turns it off (default)
#
#CONFIG_mysql_dump_master_data=
# Included stored routines (procedures and functions) for the dumped databases in the output. Use of this option
# requires the SELECT privilege for the mysql.proc table. The output generated by using --routines contains
# CREATE PROCEDURE and CREATE FUNCTION statements to re-create the routines. However, these statements do not
# include attributes such as the routine creation and modification timestamps. This means that when the routines
# are reloaded, they will be created with the timestamps equal to the reload time.
#
# If you require routines to be re-created with their original timestamp attributes, do not use --routines. Instead,
# dump and reload the contents of the mysql.proc table directly, using a MySQL account that has appropriate privileges
# for the mysql database.
#
# This option was added in MySQL 5.0.13. Before that, stored routines are not dumped. Routine DEFINER values are not
# dumped until MySQL 5.0.20. This means that before 5.0.20, when routines are reloaded, they will be created with the
# definer set to the reloading user. If you require routines to be re-created with their original definer, dump and
# load the contents of the mysql.proc table directly as described earlier.
#
CONFIG_mysql_dump_full_schema='no'
# Backup status of table(s) in textfile. This is very helpful when restoring backups, since it gives an idea, what changed
# in the meantime.
CONFIG_mysql_dump_dbstatus='yes'
# Backup dump settings
# Include CREATE DATABASE in backup?
CONFIG_mysql_dump_create_database='yes'
# Separate backup directory and file for each DB? (yes or no)
CONFIG_mysql_dump_use_separate_dirs='yes'
# Choose Compression type. (gzip or bzip2)
CONFIG_mysql_dump_compression='gzip'
# Store an additional copy of the latest backup to a standard
# location so it can be downloaded by third party scripts.
#CONFIG_mysql_dump_latest='no'
# Remove all date and time information from the filenames in the latest folder.
# Runs, if activated, once after the backups are completed. Practically it just finds all files in the latest folder
# and removes the date and time information from the filenames (if present).
#CONFIG_mysql_dump_latest_clean_filenames='no'
# Create differential backups. Master backups are created weekly at #$CONFIG_do_weekly weekday. Between master backups,
# diff is used to create differential backups relative to the latest master backup. In the Manifest file, you find the
# following structure
# $filename md5sum $md5sum diff_id $diff_id rel_id $rel_id
# where each field is separated by the tabular character '\t'. The entries with $ at the beginning mean the actual values,
# while the others are just for readability. The diff_id is the id of the differential or master backup which is also in
# the filename after the last _ and before the suffixes begin, i.e. .diff, .sql and extensions. It is used to relate
# differential backups to master backups. The master backups have 0 as $rel_id and are thereby identifiable. Differential
# backups have the id of the corresponding master backup as $rel_id.
#
# To ensure that master backups are kept long enough, the value of $CONFIG_rotation_daily is set to a minimum of 21 days.
#
CONFIG_mysql_dump_differential='no'
# Notification setup
# What would you like to be mailed to you?
# - log : send only log file
# - files : send log file and sql files as attachments (see docs)
# - stdout : will simply output the log to the screen if run manually.
# - quiet : Only send logs if an error occurs to the MAILADDR.
#CONFIG_mailcontent='stdout'
# Set the maximum allowed email size in k. (4000 = approx 5MB email [see docs])
#CONFIG_mail_maxattsize=4000
# Allow packing of files with tar and splitting it in pieces of CONFIG_mail_maxattsize.
#CONFIG_mail_splitandtar='yes'
# Use uuencode instead of mutt. WARNING: Not all email clients work well with uuencoded attachments.
#CONFIG_mail_use_uuencoded_attachments='no'
# Email Address to send mail to? (user@domain.com)
#CONFIG_mail_address='root'
# Encryption
# Do you wish to encrypt your backups using openssl?
CONFIG_encrypt='no'
# Choose a password to encrypt the backups.
#CONFIG_encrypt_password='password0123'
# Other
# Backup local files, i.e. maybe you would like to backup your my.cnf (mysql server configuration), etc.
# These files will be tar'ed, depending on your compression option CONFIG_mysql_dump_compression compressed and
# depending on the option CONFIG_encrypt encrypted.
#
# Note: This could also have been accomplished with CONFIG_prebackup or CONFIG_postbackup.
#CONFIG_backup_local_files=()
# Command to run before backups (uncomment to use)
#CONFIG_prebackup="/etc/mysql-backup-pre"
# Command run after backups (uncomment to use)
CONFIG_postbackup="/var/opt/backups/taskfreak/taskfreak_backup.sh"
# Uncomment to activate! This will give folders rwx------
# and files rw------- permissions.
umask 0077
# dry-run, i.e. show what you are gonna do without actually doing it
# inactive: =0 or commented out
# active: uncommented AND =1
#CONFIG_dryrun=1
Le fichier est créé avec un droit de modification et exécution uniquement pour le compte root
:
#sudo chmod 640 /var/opt/backups/taskfreak/taskfreak_automysqlbackup.conf #sudo chown root:root /var/opt/backups/taskfreak/taskfreak_automysqlbackup.conf
Les paramètres mis en place sont:
Paramètre | Valeur |
---|---|
CONFIG_mysql_dump_username | backup |
CONFIG_mysql_dump_password | Mot de passe du compte backup. |
CONFIG_mysql_dump_host | localhost
L'utilitaire est installé sur la même machine que MySQL. |
CONFIG_backup_dir | /var/opt/backups/taskfreak/db
Ce répertoire est à créer. |
CONFIG_multicore | yes |
CONFIG_multicore_threads | 2
La machine est un bi-processeur avec deux coeurs. |
CONFIG_db_names | ( 'taskfreak' )
Seule la base taskfreak est gérée dans cette configuration. |
CONFIG_do_monthly | 0
Les sauvegardes mensuelles ne sont pas souhaitées dans le cadre de cette utilisation. |
CONFIG_do_weekly | 0
Les sauvegardes hebdomadaires ne sont pas souhaitées dans le cadre de cette utilisation. |
CONFIG_rotation_daily | 1
Seule la sauvegarde du jour est conservée. En effet, l'installation faite n'est pas critique et comme les différentiels peuvent être gérés par Duplicity, il sera possible de restaurer des anciennes sauvegardes. |
CONFIG_mysql_dump_port | 3306 |
CONFIG_mysql_dump_full_schema | no |
CONFIG_mysql_dump_dbstatus | yes |
CONFIG_mysql_dump_create_database | yes
Ce qui permet d'avoir les scripts de création de la abse. |
CONFIG_mysql_dump_use_separate_dirs | yes |
CONFIG_mysql_dump_compression | gzip
Les sauvegardes seront compressées ainsi. |
CONFIG_mysql_dump_differential | no
Les sauvegardes sont complêtes à chaque fois. |
CONFIG_postbackup | /var/opt/backups/taskfreak/taskfreak_backup.sh
Ce script sera déclenché à la fin de la sauvegarde, permettant de planifier la synchronisation à partir de Duplicity. |
umask | 0077
Seul le compte root aura accès aux sauvegardes. |
Le répertoire /var/opt/backups/taskfreak/db
doit être créé.
#sudo mkdir /var/opt/backups/taskfreak/db #sudo chown root:root /var/opt/backups/taskfreak/db #sudo chmod 750 /var/opt/backups/taskfreak/db
Le script taskfreak_backup.sh
est mis en place, avec des sécurités autorisant uniquement le compte root
à le modifier, dans le répertoire /var/opt/backups/taskfreak
avec le code suivant:
#!/bin/bash
dateLogFormat="+%Y-%m-%d %H:%M";
# Backup log
pathLog="/var/log/backups/taskfreak_backup.log";
echo "[$(date "$dateLogFormat")] Start backup" >> $pathLog;
echo "[$(date "$dateLogFormat")] Start upload with duplicity" >> $pathLog;
export PASSPHRASE=DUPLICITY PASSPHRASE
export FTP_PASSWORD=USER_PASSWORD
duplicity remove-all-but-n-full 3 --force ftp://FTP_LOGIN@HOST/backup/taskfreak >> $pathLog;
duplicity --include '/var/opt/taskfreak*' --include '/var/opt/backups/taskfreak/db' --include '/etc/apache2/sites-available/default.conf'
--include '/etc/apache2/sites-enabled/000-default.conf' --exclude '**' --full-if-older-than 7D / ftp://FTP_LOGIN@HOST/backup/taskfreak >> $pathLog;
unset PASSPHRASE
unset FTP_PASSWORD
echo "[$(date "$dateLogFormat")] End upload with duplicity" >> $pathLog;
echo "[$(date "$dateLogFormat")] End backup" >> $pathLog;
Attention à l'utilisation de l'instruction export
, surtout pour la PASSPHRASE. En effet, si celle-ci contient des espaces, il est impératif de la placer entre le caractère "
.
Il n'est pas nécessaire de positionne le droit d'exécution sur ce fichier.
#sudo chmod 640 /var/opt/backups/taskfreak/taskfreak_backup.sh #sudo chown root:root /var/opt/backups/taskfreak/taskfreak_backup.sh
Le fonctionnement de ce script est assez simple. Puis deux variables d'environnement sont mises en place:
- PASSPHRASE: Phrase pour le cryptage des données par duplicity.
- FTP_PASSWORD: Le mot de passe FTP utilisé pour se connecté via duplicity.
La première instruction, avec l'argument remove-all-but-n-full 3
, va conserver les trois dernières sauvegardes complètes. Puis la seconde instruction, avec l'argument --full-if-older-than 7D
effectue une sauvegarde incrémentale uniquement si la précédente complète est plus ancienne de sept jours.
Le résultat de l'export est ensuite envoyé sur un serveur FTP, configuré par la value HOST
, en utilisant le login FTP_LOGIN
et le mot de passe USER_PASSWORD
placé dans la variable FTP_PASSWORD
. Les sauvegardes sont stockées à l'emplacement backup/taskfreak
à la racine du compte après connexion sur FTP.
Enfin, les exécutions sont tracées dans la log /var/log/backups/taskfreak_backup.log
.
Afin de faciliter le déploiement de cette exécution sous crontab, un deuxième script est mis en place afin d'exécuter AutoMySQLBackup avec le fichier de configuration. Le script taskfreak_automysqlbackup.sh
est mis en place, avec des sécurités autorisant uniquement le compte root
à le modifier, dans le répertoire /var/opt/backups/taskfreak
avec le code suivant:
#!/bin/bash
/var/opt/automysqlbackup/automysqlbackup /var/opt/backups/taskfreak/taskfreak_automysqlbackup.conf >> /var/log/backups/taskfreak_backup_db.log
Le script est créé avec un droit de modification et exécution uniquement pour le compte root
:
#sudo chmod 750 /var/opt/backups/taskfreak/taskfreak_automysqlbackup.sh #sudo chown root:root /var/opt/backups/taskfreak/taskfreak_automysqlbackup.sh
Les messages d'exécution de AutoMySQLBackup sont redirigés vers la log /var/log/backups/taskfreak_backup_db.log
.
Exemples
Le script n'accepte aucun argument. L'exécution s'effectue simplement par la ligne suivante:
#./taskfreak_automysqlbackup.sh
Planification
Une fois que le script de sauvegarde est mis en place, il est possible de l'exécuter manuellement. Mais l'objectif est de l'exécuter automatiquement et régulièrement sans s'en préoccuper. Dans le cadre de cette implémentation, la planification est réalisée à l'aide de l'outil Crontab disponible sur les systèmes Linux. L'outil Anacron n'a pas été utilisé car les planifications souhaitées doivent se faire à des heures et des jours particuliers.
La mise en place s'effectue en modifiant le fichier /etc/crontab
pour y ajouter une ligne.
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
00 1 * * * root cd / && /var/opt/backups/taskfreak/taskfreak_automysqlbackup.sh
#
Les sauvegardes sont planifiées à 1h00 AM, tous les jours de la semaine, par l'exécution de la commande cd / && /var/opt/backups/taskfreak/taskfreak_automysqlbackup.sh
.
Gestions des logs
Des fichiers de log sont créés par le script mis en place. Comme pour l'ensemble des produits, une rotation de ces logs est mise en place, à l'aide de l'outil Logrotate.
L'ensemble des logs se trouvent donc dans le répertoire /var/log/backups
avec les noms taskfreak_backup_db.log
et taskfreak_backup.log
. La configuration permet une rotation hebdomadaire, en conservant 3 rotations. Les rotations sont compressées, en asynchrone, et créées avec un accès en modification au compte root.
Cette configuration est mise en place dans le fichier taskfreak_backup
, sous le répertoire /etc/logrotate.d
/var/log/backups/taskfreak*.log {
weekly
missingok
rotate 3
compress
delaycompress
notifempty
create 640 root root
}