🥇Yandex.Cloud の 1C-Bitrix 上の Web サイトを使用した増分 VDS バックアップ

「2C-Bitrix: Site Management」上のサイト (ファイルと mysql データベース) のバックアップを 1 日に 90 回作成し、変更履歴を XNUMX 日間保存する必要がありました。

このサイトは、7C-Bitrix: Web 環境がインストールされた CentOS 1 OS を実行している VDS 上にあります。さらに、OS 設定のバックアップコピーを作成します。

要件：

頻度 - 2日XNUMX回。
過去 90 日間はコピーを保管しておいてください。
必要に応じて、特定の日付の個別のファイルを取得する機能。
バックアップは VDS 以外のデータセンターに保存する必要があります。
どこからでも (別のサーバー、ローカルコンピューターなど) バックアップにアクセスできる機能。

重要な点は、追加のスペースとシステムリソースの消費を最小限に抑えてバックアップを迅速に作成できることです。

これは、システム全体を迅速に復元するためのスナップショットに関するものではなく、ファイル、データベース、および変更履歴に関するものです。

背景：

XEN 仮想化上の VDS。
OS CentOS 7;
1C-Bitrix: Web 環境。
「1C-Bitrix: Site Management」標準バージョンに基づく Web サイト。
ファイルサイズは 50 GB であり、増加します。
データベースのサイズは 3 GB であり、今後増加します。

私はすぐに 1C-Bitrix に組み込まれている標準バックアップを除外しました。次の理由から、小規模なサイトにのみ適しています。

毎回サイトの完全なコピーが作成されるため、各コピーはファイルが占有するのと同じ量のスペースを占有します。私の場合は 50 GB です。
バックアップは PHP を使用して行われますが、このような大量のファイルではバックアップは不可能であり、サーバーに過負荷がかかり、完了しません。
そしてもちろん、完全なコピーを保管する場合、90 日間という話はあり得ません。

ホスティング会社が提供するソリューションは、VDS と同じデータセンターにある、別のサーバー上にあるバックアップディスクです。 FTP 経由でディスクを操作して独自のスクリプトを使用するか、ISPManager が VDS にインストールされている場合はそのバックアップモジュールを使用して作業できます。同じデータセンターを使用するため、このオプションは適していません。

上記すべてのことから、私にとって最良の選択は、Yandex.Cloud (オブジェクトストレージ) または Amazon S3 (Amazon Simple Storage Service) で独自のスクリプトを使用した増分バックアップです。

これには以下が必要です。

VDS への root アクセス。
二重性ユーティリティがインストールされています。
Yandex.Cloud のアカウント。

増分バックアップ — 前回のバックアップ以降に変更されたデータのみをアーカイブする方法。

二枚舌 — rsync アルゴリズムを使用し、Amazon S3 と連携できるバックアップユーティリティ。

Yandex.Cloud 対 Amazon S3

この場合、私にとっては Yandex.Cloud と Amazon S3 の間に違いはありません。 Yandex は Amazon S3 API の大部分をサポートしているため、S3 を操作するために存在するソリューションを使用して操作できます。私の場合、これは duplicity ユーティリティです。

Yandex の主な利点はルーブルでの支払いかもしれませんが、大量のデータがある場合は為替レートに関係がありません。速度の点では、Amazon のヨーロッパのデータセンターは、Yandex のロシアのデータセンターと同等に動作します。たとえば、フランクフルトを使用できます。以前は同様のタスクに Amazon S3 を使用していましたが、今回は Yandex を試してみることにしました。

Yandex.Cloudのセットアップ

1. Yandex.Cloud で支払いアカウントを作成する必要があります。これを行うには、Yandex アカウントを通じて Yandex.Cloud にログインするか、新しいアカウントを作成する必要があります。

2. 「クラウド」を作成します。

3. 「クラウド」に「カタログ」を作成します。

4. 「カタログ」に対して「サービスアカウント」を作成します。

5. 「サービスアカウント」のキーを作成します。

6. キーは将来必要になるため、保管しておいてください。

7. 「ディレクトリ」には「バケット」を作成し、そこにファイルを入れます。

8. 制限を設定して「コールドストレージ」を選択することをお勧めします。

サーバー上でスケジュールされたバックアップを設定する

このガイドは、基本的な管理スキルを前提としています。

1. VDS に Duplicity ユーティリティをインストールする

yum install duplicity

2. mysql ダンプ用のフォルダーを作成します。私の場合は、VDS ルートの /backup_db です。

3. bash スクリプト用のフォルダー /backup_scripts を作成し、バックアップを実行する最初のスクリプト /backup_scripts/backup.sh を作成します。

スクリプトの内容:

#!`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. 初めてスクリプトを実行して結果を確認すると、ファイルが「バケット」に表示されるはずです。

`which bash` /backup_scripts/backup.sh

5. root ユーザーが 2 日に XNUMX 回、または必要な頻度で実行するスクリプトを cron に追加します。

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

Yandex.Cloudからのデータの回復

1. 回復フォルダー /backup_restore を作成します

2. リカバリ用の bash スクリプトを作成します /backup_scripts/restore.sh

特定のファイルを復元する最も一般的な例を示します。

#!`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. スクリプトを実行し、結果を待ちます。

`which bash` /backup_scripts/backup.sh

/backup_restore/ フォルダーには、以前にバックアップしたindex.php ファイルがあります。

ニーズに合わせてさらに細かく調整できます。

マイナス重複

二重性には 1 つの欠点があります。それは、チャネル使用制限を設定できないことです。通常のチャネルでは問題はありませんが、DDoS で保護されたチャネルを 2 日あたりの高速充電で使用する場合は、XNUMX ～ XNUMX メガビットの制限を設定できるようにしたいと考えています。

結論として

Yandex.Cloud または Amazon S3 のバックアップでは、他のサーバーやローカルコンピューターからアクセスできるサイトと OS 設定の独立したコピーが提供されます。さらに、このコピーはホスティングコントロールパネルにも Bitrix 管理パネルにも表示されないため、セキュリティが強化されます。

最悪のシナリオでは、いつでも新しいサーバーを組み立ててサイトを展開できます。ただし、最も人気のある機能は、特定の日付のファイルにアクセスする機能です。

この手法は、1C-Bitrix だけでなく、任意のエンジン上の任意の VDS または専用サーバーおよびサイトで使用できます。 OSはCentOS以外のUbuntuやDebianなどでも構いません。

出所： habr.com

Yandex.Cloud の 1C-Bitrix 上のサイトによる増分 VDS バックアップ

Yandex.Cloud 対 Amazon S3

Yandex.Cloudのセットアップ

サーバー上でスケジュールされたバックアップを設定する

Yandex.Cloudからのデータの回復

結論として

コメントを追加します返信をキャンセル

Yandex.Cloud の 1C-Bitrix 上のサイトによる増分 VDS バックアップ

Yandex.Cloud 対 Amazon S3

Yandex.Cloudのセットアップ

サーバー上でスケジュールされたバックアップを設定する

Yandex.Cloudからのデータの回復

結論として

コメントを追加します 返信をキャンセル

コメントを追加します返信をキャンセル