🥇پشتیبان گیری افزایشی VDS با وب سایت در 1C-Bitrix در Yandex.Cloud

لازم بود 2 بار در روز از سایت به 1C-Bitrix: Site Management (فایل ها و پایگاه داده mysql) نسخه پشتیبان تهیه کنم و تاریخچه تغییرات را به مدت 90 روز ذخیره کنم.

این سایت بر روی یک VDS دارای CentOS 7 با نصب «1C-Bitrix: Web Environment» قرار دارد. علاوه بر این، یک نسخه پشتیبان از تنظیمات سیستم عامل تهیه کنید.

مورد نیاز:

فرکانس - 2 بار در روز؛
کپی ها را برای 90 روز گذشته نگه دارید.
توانایی دریافت فایل های فردی برای یک تاریخ خاص، در صورت لزوم؛
نسخه پشتیبان باید در مرکز داده ای غیر از VDS ذخیره شود.
امکان دسترسی به نسخه پشتیبان از هر کجا (سرور دیگر، کامپیوتر محلی و غیره).

نکته مهم امکان ایجاد سریع پشتیبان با حداقل مصرف فضای اضافی و منابع سیستم بود.

این در مورد یک عکس فوری برای بازیابی سریع کل سیستم نیست، بلکه در مورد فایل ها و پایگاه داده و تاریخچه تغییرات است.

اطلاعات اولیه:

VDS در مجازی سازی XEN.
سیستم عامل CentOS 7؛
1C-Bitrix: محیط وب.
سایت مبتنی بر "1C-Bitrix: مدیریت سایت"، نسخه استاندارد؛
حجم فایل 50 گیگابایت است و رشد خواهد کرد.
حجم پایگاه داده 3 گیگابایت است و رشد خواهد کرد.

نسخه پشتیبان استاندارد ساخته شده در 1C-Bitrix - بلافاصله حذف می شود. این فقط برای سایت های کوچک مناسب است، زیرا:

هر بار یک کپی کامل از سایت تهیه می کند، به ترتیب، هر کپی به همان اندازه که من فایل ها را اشغال می کنم، در مورد من 50 گیگابایت است.
پشتیبان گیری با استفاده از PHP انجام می شود که با چنین حجمی از فایل ها غیرممکن است، سرور را بارگذاری می کند و هرگز تمام نمی شود.
و البته، هنگام ذخیره یک نسخه کامل، هیچ صحبتی از 90 روز وجود ندارد.

راه حلی که ارائه می‌دهد میزباناین یک دیسک پشتیبان است که در همان مرکز داده VDS قرار دارد، اما روی یک سرور متفاوت. می‌توانید از طریق FTP به دیسک دسترسی پیدا کنید و از اسکریپت‌های خودتان استفاده کنید، یا اگر ISPManager روی VDS نصب شده باشد، از طریق ماژول پشتیبان آن. این گزینه مناسب نیست زیرا از همان مرکز داده استفاده می‌کند.

از همه موارد بالا، بهترین انتخاب برای من یک پشتیبان گیری افزایشی مطابق با سناریوی خودم در Yandex.Cloud (ذخیره سازی اشیا) یا Amazon S3 (سرویس ذخیره سازی ساده آمازون) است.

این مستلزم:

دسترسی ریشه به VDS؛
ابزار duplicity نصب شده.
حساب در Yandex.Cloud.

پشتیبان گیری افزایشی - روشی که در آن تنها داده هایی که از آخرین نسخه پشتیبان تغییر کرده اند بایگانی می شوند.
دوگانگی - یک ابزار پشتیبان گیری که از الگوریتم های rsync استفاده می کند و می تواند با Amazon S3 کار کند.

Yandex.Cloud در مقابل آمازون S3

هیچ تفاوتی بین Yandex.Cloud و Amazon S3 در این مورد برای من وجود ندارد. Yandex از بخش اصلی Amazon S3 API پشتیبانی می کند، بنابراین می توانید با استفاده از راه حل های موجود برای کار با S3 با آن کار کنید. در مورد من، این ابزار duplicity است.

مزیت اصلی Yandex می تواند پرداخت به روبل باشد، اگر داده های زیادی وجود داشته باشد، هیچ پیوندی به دوره وجود نخواهد داشت. از نظر سرعت، مراکز داده اروپایی آمازون متناسب با مراکز روسی در Yandex کار می کنند، به عنوان مثال می توانید از فرانکفورت استفاده کنید. من قبلاً از Amazon S3 برای کارهای مشابه استفاده می کردم ، اکنون تصمیم گرفتم Yandex را امتحان کنم.

راه اندازی Yandex.Cloud

1. شما باید یک حساب صورتحساب در Yandex.Cloud ایجاد کنید. برای انجام این کار، باید از طریق حساب Yandex خود وارد Yandex.Cloud شوید یا یک حساب جدید ایجاد کنید.

2. ابر ایجاد کنید.

3. در "ابر" یک "کاتالوگ" ایجاد کنید.

4. برای "کاتالوگ" یک "حساب خدمات" ایجاد کنید.

5. برای "حساب سرویس" کلید ایجاد کنید.

6. کلیدها را نگه دارید، در آینده به آنها نیاز خواهید داشت.

7. برای "کاتالوگ" یک "سطل" ایجاد کنید، فایل ها در آن قرار می گیرند.

8. من توصیه می کنم یک محدودیت تعیین کنید و "ذخیره سرد" را انتخاب کنید.

راه اندازی پشتیبان گیری برنامه ریزی شده روی سرور

این راهنما مهارت های اساسی اداری را در نظر می گیرد.

1. ابزار duplicity را روی VDS نصب کنید

yum install duplicity

2. یک پوشه برای dumps mysql ایجاد کنید، در مورد من /backup_db در ریشه VDS است.

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. اسکریپت را برای اولین بار اجرا کنید و نتیجه را بررسی کنید، فایل ها باید در Bucket ظاهر شوند.

`which bash` /backup_scripts/backup.sh

5. یک اسکریپت به cron اضافه کنید تا کاربر ریشه 2 بار در روز یا هر دفعه که نیاز دارید اجرا شود.

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 را پیدا خواهید کرد که قبلاً در نسخه پشتیبان وجود داشت.

شما می توانید تنظیمات دقیق تری را متناسب با نیاز خود انجام دهید.

منهای دوگانگی

Duplicity یک اشکال دارد - هیچ راهی برای تعیین محدودیت استفاده از کانال وجود ندارد. با یک کانال معمولی، این مشکلی ایجاد نمی کند، اما با یک کانال محافظت شده با DDoS با صورتحساب سرعت در روز، می خواهم بتوانم محدودیت 1-2 مگابیت را تعیین کنم.

به عنوان نتیجه گیری

پشتیبان‌گیری در Yandex.Cloud یا Amazon S3 یک کپی مستقل از وب‌سایت و تنظیمات سیستم عامل شما فراهم می‌کند که از هر سرور یا رایانه محلی دیگری قابل دسترسی است. این کپی برای هیچ‌کس قابل مشاهده نیست. کنترل پنل ها میزبانی وب، و نه در پنل مدیریت Bitrix، که امنیت بیشتری را فراهم می‌کند.

در بدترین نتیجه، می توانید یک سرور جدید بسازید و سایت را برای هر تاریخی مستقر کنید. اگرچه بیشترین قابلیت درخواستی، امکان دسترسی به فایل برای یک تاریخ خاص خواهد بود.

شما می توانید از این تکنیک با هر سرور VDS یا اختصاصی و سایت ها در هر موتوری استفاده کنید، نه تنها 1C-Bitrix. سیستم عامل همچنین می تواند غیر از CentOS باشد، مانند اوبونتو یا دبیان.

منبع: www.habr.com