Sauvegarde incrémentielle VDS avec un site sur 1C-Bitrix dans Yandex.Cloud

J'avais besoin de faire des sauvegardes du site sur « 2C-Bitrix : Gestion du site » (fichiers et base de données mysql) deux fois par jour et de stocker un historique des modifications pendant 1 jours.

Le site est situé sur un VDS exécutant le système d'exploitation CentOS 7 avec 1C-Bitrix : Web Environment installé. De plus, faites une copie de sauvegarde des paramètres de votre système d’exploitation.

Exigences:

• Fréquence - 2 fois par jour ;
• Conservez des copies des 90 derniers jours ;
• La possibilité d'obtenir des dossiers individuels pour une date précise, si nécessaire ;
• La sauvegarde doit être stockée dans un centre de données autre que VDS ;
• La possibilité d'accéder à la sauvegarde depuis n'importe où (un autre serveur, un ordinateur local, etc.).

Un point important était la possibilité de créer rapidement des sauvegardes avec une consommation minimale d'espace et de ressources système supplémentaires.

Il ne s'agit pas d'un instantané permettant de restaurer rapidement l'ensemble du système, mais de fichiers, de bases de données et de l'historique des modifications.

Contexte:

• VDS sur virtualisation XEN ;
• Système d'exploitation CentOS 7 ;
• 1C-Bitrix : Environnement Web ;
• Site Web basé sur « 1C-Bitrix : Gestion de site », version Standard ;
• La taille du fichier est de 50 Go et va augmenter ;
• La taille de la base de données est de 3 Go et va croître.

J'ai immédiatement exclu la sauvegarde standard intégrée à 1C-Bitrix. Il ne convient qu'aux petits sites, car :

• Il crée une copie complète du site à chaque fois, donc chaque copie occupera la même quantité d'espace que les fichiers, dans mon cas, c'est 50 Go.
• La sauvegarde se fait en PHP, ce qui est impossible avec de tels volumes de fichiers, cela surchargerait le serveur et ne se terminerait jamais.
• Et bien sûr, on ne peut pas parler de 90 jours pour stocker une copie complète.

La solution proposée par l'hébergeur est un disque de sauvegarde situé dans le même centre de données que le VDS, mais sur un serveur différent. Vous pouvez travailler avec le disque via FTP et utiliser vos propres scripts, ou si ISPManager est installé sur le VDS, via son module de sauvegarde. Cette option n'est pas adaptée en raison de l'utilisation du même centre de données.

Parmi tout ce qui précède, le meilleur choix pour moi est une sauvegarde incrémentielle utilisant mon propre script dans Yandex.Cloud (Object Storage) ou Amazon S3 (Amazon Simple Storage Service).

Cela nécessite:

• accès root au VDS ;
• utilitaire de duplicité installé ;
• compte dans Yandex.Cloud.

Sauvegarde incrémentielle — une méthode dans laquelle seules les données modifiées depuis la dernière sauvegarde sont archivées.

duplicité - un utilitaire de sauvegarde qui utilise des algorithmes rsync et peut fonctionner avec Amazon S3.

Yandex.Cloud et Amazon S3

Dans ce cas, il n'y a aucune différence entre Yandex.Cloud et Amazon S3 pour moi. Yandex prend en charge la majeure partie de l'API Amazon S3, vous pouvez donc l'utiliser en utilisant les solutions existantes pour travailler avec S3. Dans mon cas, il s'agit de l'utilitaire de duplicité.

Le principal avantage de Yandex peut être le paiement en roubles : s'il y a beaucoup de données, il n'y aura aucun lien avec le taux de change. En termes de vitesse, les centres de données européens d'Amazon fonctionnent de manière comparable aux centres de données russes de Yandex ; par exemple, vous pouvez utiliser Francfort. J'utilisais auparavant Amazon S3 pour des tâches similaires, j'ai maintenant décidé d'essayer Yandex.

Configuration de Yandex.Cloud

1. Vous devez créer un compte de paiement dans Yandex.Cloud. Pour ce faire, vous devez vous connecter à Yandex.Cloud via votre compte Yandex ou en créer un nouveau.

2. Créez un "Cloud".


3. Dans le « Cloud », créez un « Catalogue ».


4. Pour le « Catalogue », créez un « Compte de service ».


5. Créez des clés pour le « Compte de service ».


6. Conservez les clés, elles seront nécessaires à l'avenir.


7. Pour le « Répertoire », créez un « Bucket », les fichiers y entreront.


8. Je recommande de définir une limite et de sélectionner « Cold Storage ».

Configuration des sauvegardes planifiées sur le serveur

Ce guide suppose des compétences administratives de base.

1. Installez l'utilitaire de duplicité sur le VDS

yum install duplicity

2. Créez un dossier pour les dumps MySQL, dans mon cas, il s'agit de /backup_db à la racine du VDS

3. Créez un dossier pour les scripts bash /backup_scripts et créez le premier script qui effectuera les sauvegardes /backup_scripts/backup.sh

Contenu du script :

#!`which bash`


# /backup_scripts/backup.sh

# Это условие проверяет не идёт ли в данный момент процесс резервного копирования, если идёт, то на email отправляется сообщение об ошибке (этот блок можно не использовать)
if [ -f /home/backup_check.mark ];
then

DATE_TIME=`date +"%d.%m.%Y %T"`;

/usr/sbin/sendmail -t <<EOF
From:backup@$HOSTNAME
To:<Ваш EMAIL>
Subject:Error backup to YANDEX.CLOUD
Content-Type:text/plain; charset=utf-8
Error backup to YANDEX.CLOUD

$DATE_TIME
EOF

else

# Основной блок отвечающий за резервное копирование
# Если нет ощибки ставим метку и запускаем backup

echo '' > /home/backup_check.mark;


# Удаляем файлы с дампами базы оставшиеся от предыдущего backup

/bin/rm -f /backup_db/*


# Делаем дамп всех mysql баз, предполагается что доступ добавлен в файле /root/.my.cnf

DATETIME=`date +%Y-%m-%d_%H-%M-%S`;

`which mysqldump` --quote-names --all-databases | `which gzip` > /backup_db/DB_$DATETIME.sql.gz


# Добавляем данные для отправки в Яндекс.

export PASSPHRASE=<Придумайте пароль для шифрования архива>
export AWS_ACCESS_KEY_ID=<Идентификатор ключа полученный у Яндекса>
export AWS_SECRET_ACCESS_KEY=<Секретный ключ полученный у Яндекса>


# Запускаем duplicity для резервирования необходимых папок на сервере.
# Данная команда будет создавать полный backup раз в месяц и до следующего месяца добавлять инкрементальные к нему
# -- exclude это папки, которые нужно исключить, я исключаю все папки с кешем битрикса
# --include папки которые нужно резервировать в моём случае это:
# - /backup_db
# - /home
# - /etc
# s3://storage.yandexcloud.net/backup , backup это имя созданного выше бакета

# Техническая особенность и значения некоторых параметров:
# Две строки "--exclude='**'" и "/" нужны, чтобы можно было выше оперировать --include и --exclude для разных папок. Эти две строчки сначала добавляют в бэкап весь сервер "/", потом исключают его "--exclude='**'"
# --full-if-older-than='1M' - создавать полную копию каждый месяц
# --volsize='512' - максимальный размер каждого из файлов в бэкапе в мегабайтах
# --log-file='/var/log/duplicity.log' - куда писать лог файл

`which duplicity` 
    --s3-use-ia --s3-european-buckets 
    --s3-use-new-style 
    --s3-use-multiprocessing 
    --s3-multipart-chunk-size='128' 
    --volsize='512' 
    --no-print-statistics 
    --verbosity=0 
    --full-if-older-than='1M' 
    --log-file='/var/log/duplicity.log' 
    --exclude='**/www/bitrix/backup/**' 
    --exclude='**/www/bitrix/cache/**' 
    --exclude='**/www/bitrix/cache_image/**' 
    --exclude='**/www/bitrix/managed_cache/**' 
    --exclude='**/www/bitrix/managed_flags/**' 
    --exclude='**/www/bitrix/stack_cache/**' 
    --exclude='**/www/bitrix/html_pages/*/**' 
    --exclude='**/www/bitrix/tmp/**' 
    --exclude='**/www/upload/tmp/**' 
    --exclude='**/www/upload/resize_cache/**' 
    --include='/backup_db' 
    --include='/home' 
    --include='/etc' 
    --exclude='**' 
    / 
    s3://storage.yandexcloud.net/backup



# Данная команда нужна для чистки.
# Она оставляет 3 последних полных backup и ассоциированных с ними инкрементальных backup.
# Т.о. у меня остаются backup за 3 месяца, т.к. первая команда каждый месяц делает новый полный backup

`which duplicity` remove-all-but-n-full 3 --s3-use-ia --s3-european-buckets --s3-use-new-style --verbosity=0 --force s3://storage.yandexcloud.net/backup



unset PASSPHRASE
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY

# Удаляем метку об идущем backup

/bin/rm -f /home/backup_check.mark;

fi

4. Exécutez le script pour la première fois et vérifiez le résultat, les fichiers devraient apparaître dans le « Bucket ».

`which bash` /backup_scripts/backup.sh

5. Ajoutez un script à cron pour que l'utilisateur root s'exécute 2 fois par jour ou à la fréquence dont vous avez besoin.

10 4,16 * * * `which bash` /backup_scripts/backup.sh

Récupération de données depuis Yandex.Cloud

1. Créez un dossier de récupération /backup_restore

2. Créer un script bash pour la récupération /backup_scripts/restore.sh

Je donne l'exemple le plus populaire de restauration d'un fichier spécifique :

#!`which bash`

export PASSPHRASE=<Пароль для шифрования архива используемый при бэкапе>
export AWS_ACCESS_KEY_ID=<Идентификатор ключа полученный у Яндекса>
export AWS_SECRET_ACCESS_KEY=<Секретный ключ полученный у Яндекса>

# 3 примера, раскомментировать нужный

# Получить статус backup
#`which duplicity` collection-status s3://storage.yandexcloud.net/backup

# Восстановить index.php из корня сайта
#`which duplicity` --file-to-restore='home/bitrix/www/index.php' s3://storage.yandexcloud.net/backup /backup_restore/index.php

# Восстановить index.php из корня сайта 3х дневной давности
#`which duplicity` --time='3D' --file-to-restore='home/bitrix/www/index.php' s3://storage.yandexcloud.net/backup /backup_restore/index.php

unset PASSPHRASE
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY

3. Exécutez le script et attendez le résultat.

`which bash` /backup_scripts/backup.sh

Dans le dossier /backup_restore/, vous trouverez le fichier index.php précédemment sauvegardé.

Vous pouvez effectuer des réglages plus fins en fonction de vos besoins.

Moins de duplication

la duplicité présente un inconvénient : il n'est pas possible de définir une limite d'utilisation des canaux. Avec un canal normal, cela ne pose pas de problème, mais lorsque j'utilise un canal protégé contre les DDoS avec une charge rapide par jour, j'aimerais pouvoir fixer une limite de 1 à 2 mégabits.

Comme conclusion

La sauvegarde dans Yandex.Cloud ou Amazon S3 fournit une copie indépendante des paramètres du site et du système d'exploitation accessible depuis n'importe quel autre serveur ou ordinateur local. De plus, cette copie n'est visible ni dans le panneau de contrôle d'hébergement ni dans le panneau d'administration Bitrix, ce qui offre une sécurité supplémentaire.

Dans le pire des cas, vous pouvez assembler un nouveau serveur et déployer le site à tout moment. Bien que la fonctionnalité la plus populaire soit la possibilité d'accéder à un fichier pour une date spécifique.

Vous pouvez utiliser cette technique avec n'importe quel serveur et site VDS ou dédié sur n'importe quel moteur, pas seulement 1C-Bitrix. Le système d'exploitation peut également être autre que CentOS, comme Ubuntu ou Debian.

Source: habr.com