🥇Inkrementelles Backup für VDS mit Website auf 1C-Bitrix in Yandex.Cloud

Ich benötigte eine tägliche Sicherung der Website auf „1C-Bitrix: Website-Management“ (Dateien und MySQL-Datenbank) sowie die Aufbewahrung von Änderungsverläufen für 90 Tage.

Die Website läuft auf einem VDS mit CentOS 7, ausgestattet mit „1C-Bitrix: Web-Umgebung“. Zusätzlich sind Backups der OS-Einstellungen erforderlich.

Anforderungen:

Häufigkeit – 2 Mal täglich;
Kopien der letzten 90 Tage aufbewahren;
Die Möglichkeit, Dateien zu einem bestimmten Datum bei Bedarf abzurufen;
Das Backup muss in einem anderen als dem VDS-Rechenzentrum gespeichert werden;
Zugriff auf das Backup von überall aus (ein anderer Server, lokaler Computer usw.).

Ein wichtiger Punkt war die Möglichkeit, Backups schnell zu erstellen, mit minimalem zusätzlichen Platzbedarf und Systemressourcen.

Es handelt sich nicht um einen Snapshot zur schnellen Wiederherstellung des gesamten Systems, sondern speziell um Dateien und die Datenbank sowie den Änderungsverlauf.

Eckdaten:

VDS mit XEN-Virtualisierung;
OS CentOS 7;
1C-Bitrix: Web-Umgebung;
Website auf „1C-Bitrix: Website-Management“, Version Standard;
Dateigröße – 50 GB und wird wachsen;
Datenbankgröße – 3 GB und wird wachsen.

Das Standard-Backup, das in 1C-Bitrix integriert ist, habe ich sofort ausgeschlossen, da es nur für kleine Websites geeignet ist, weil:

Es erstellt jedes Mal ein vollständiges Backup der Website, was bedeutet, dass jede Kopie denselben Speicherplatz benötigt wie die Dateien, in meinem Fall sind das 50 GB.
Das Backup erfolgt mit PHP, was bei solchen Dateimengen unmöglich ist – es würde den Server überlasten und niemals abgeschlossen werden.
Und natürlich kann es bei der Speicherung einer vollständigen Kopie keine Rede von 90 Tagen sein.

Die Lösung, die angeboten wird der Hoster, ist eine Backup-Disk, die sich im selben Rechenzentrum wie der VDS, jedoch auf einem anderen Server befindet. Mit der Disk kann man über FTP arbeiten und eigene Skripte verwenden, oder wenn ISPManager auf dem VDS installiert ist, über dessen Backup-Modul. Diese Option ist aufgrund der Nutzung desselben Rechenzentrums nicht geeignet.

Aus all dem oben Gesagten ist die optimale Lösung für mich ein inkrementelles Backup mithilfe meines eigenen Skripts in Yandex.Cloud (Object Storage) oder Amazon S3 (Amazon Simple Storage Service).

Dazu benötige ich:

root-Zugriff auf den VDS;
installierte Software duplicity;
ein Konto in Yandex.Cloud.

Inkrementelles Backup — eine Methode, bei der nur die seit dem letzten Backup geänderten Daten archiviert werden.
Duplicity — ein Backup-Tool, das rsync-Algorithmen verwendet und mit Amazon S3 arbeiten kann.

Yandex.Cloud vs Amazon S3

Für mich gibt es in diesem Fall keinen Unterschied zwischen Yandex.Cloud und Amazon S3. Yandex unterstützt den Großteil der Amazon S3 APIs, sodass man mit Lösungen, die für S3 konzipiert sind, arbeiten kann. In meinem Fall ist das das Tool Duplicity.

Ein Hauptvorteil von Yandex könnte die Zahlung in Rubel sein; wenn viele Daten anfallen, ist man nicht vom Wechselkurs abhängig. In Bezug auf die Geschwindigkeit arbeiten europäische Amazon-Rechenzentren vergleichbar mit den russischen von Yandex, zum Beispiel kann man Frankfurt verwenden. Ich habe früher Amazon S3 für ähnliche Aufgaben genutzt, habe jetzt entschieden, Yandex auszuprobieren.

Konfiguration von Yandex.Cloud

1. Es ist notwendig, ein Zahlungsmittelkonto in Yandex.Cloud zu erstellen. Dazu muss man sich über sein Yandex-Konto bei Yandex.Cloud anmelden oder ein neues Konto erstellen.

2. Erstellen Sie ein „Cloud“.

3. Im „Cloud“ einen „Katalog“ erstellen.

4. Für den „Katalog“ einen „Service-Konto“ erstellen.

5. Für das „Service-Konto“ Schlüssel erstellen.

6. Schlüssel speichern, sie werden später benötigt.

7. Erstellen Sie für das 'Katalog' einen 'Bucket', in den die Dateien gelangen werden.

8. Ich empfehle, ein Limit festzulegen und 'Kaltes Speichern' auszuwählen.

Einrichtung der geplanten Datensicherung auf dem Server

Diese Anleitung setzt grundlegende Administrationskenntnisse voraus.

1. Installieren Sie das Tool duplicity auf dem VDS.

yum install duplicity

2. Erstellen Sie einen Ordner für MySQL-Dumps, in meinem Fall ist das /backup_db im Wurzelverzeichnis des VDS.

3. Erstellen Sie einen Ordner für Bash-Skripte /backup_scripts und erstellen Sie das erste Skript, das das Backup durchführen wird: /backup_scripts/backup.sh.

Inhalt des Skripts:

#!`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. Führen Sie das Skript zum ersten Mal aus und überprüfen Sie das Ergebnis; im 'Bucket' sollten Dateien erscheinen.

`which bash` /backup_scripts/backup.sh

5. Fügen Sie das Skript dem Cron-Job für den Benutzer root hinzu, um es zweimal täglich oder mit der gewünschten Frequenz auszuführen.

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

Wiederherstellung von Daten aus Yandex.Cloud

1. Erstellen Sie einen Ordner für die Wiederherstellung /backup_restore.

2. Erstellen Sie ein Bash-Skript zur Wiederherstellung /backup_scripts/restore.sh.

Hier ist das am häufigsten nachgefragte Beispiel zur Wiederherstellung einer bestimmten Datei:

#!`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. Führen Sie das Skript aus und warten Sie auf das Ergebnis.

`which bash` /backup_scripts/backup.sh

Im Ordner /backup_restore/ finden Sie die Datei index.php, die zuvor in das Backup aufgenommen wurde.

Sie können eine detailliertere Anpassung nach Ihren Bedürfnissen vornehmen.

Nachteil von Duplicity

Ein Nachteil von Duplicity ist, dass es keine Möglichkeit gibt, ein Nutzungslimit für den Kanal festzulegen. Mit einem normalen Kanal ist das kein Problem, aber wenn es um einen Kanal mit DDoS-Schutz mit tagesabhängiger Tarifgestaltung geht, würde ich gerne ein Limit von 1-2 Megabit festlegen können.

Als Ergebnis

Die Sicherung in Yandex.Cloud oder Amazon S3 bietet eine unabhängige Kopie der Website und der OS-Einstellungen, auf die von jedem anderen Server oder lokalen Computer zugegriffen werden kann. Gleichzeitig ist diese Kopie weder im Kontrollpanels Hosting noch im Administratorbereich von Bitrix sichtbar, was zusätzliche Sicherheit bietet.

Im schlimmsten Fall kann ein neuer Server eingerichtet und die Website auf ein beliebiges Datum wiederhergestellt werden. Obwohl die gefragteste Funktion die Möglichkeit ist, auf Dateien eines bestimmten Datums zuzugreifen.

Diese Methode kann mit allen VDS oder dedizierten Servern und Websites auf beliebigen Plattformen verwendet werden, nicht nur mit 1C-Bitrix. Das Betriebssystem kann ebenfalls von CentOS abweichen, zum Beispiel Ubuntu oder Debian.

Quelle: habr.com