🥇 Yandex.Cloud ۾ 1C-Bitrix تي سائيٽ سان وڌندڙ VDS بيڪ اپ

اهو ضروري هو ته منهنجي لاءِ سائيٽ جو بيڪ اپ 2C-Bitrix: سائيٽ مئنيجمينٽ 1 ڀيرا هڪ ڏينهن ۾ (فائلون ۽ mysql ڊيٽابيس) ۽ 90 ڏينهن لاءِ تبديلين جي تاريخ محفوظ ڪرڻ.

سائيٽ "7C-Bitrix: ويب ماحول" نصب ٿيل CentOS 1 سان هلندڙ وي ڊي ايس تي واقع آهي. اضافي طور تي، او ايس سيٽنگون جي بيڪ اپ ڪاپي ٺاهيو.

گهربل

تعدد - 2 ڀيرا هڪ ڏينهن؛
آخري 90 ڏينهن لاء ڪاپيون رکو؛
هڪ مخصوص تاريخ لاءِ انفرادي فائلون حاصل ڪرڻ جي صلاحيت، جيڪڏهن ضروري هجي ته؛
بيڪ اپ کي VDS کان سواءِ ڊيٽا سينٽر ۾ محفوظ ڪيو وڃي.
ڪٿي به بيڪ اپ تائين رسائي حاصل ڪرڻ جي صلاحيت (ٻيو سرور، مقامي ڪمپيوٽر، وغيره).

هڪ اهم نقطو جلدي جلدي بيڪ اپ ٺاهڻ جي صلاحيت هئي اضافي خلا ۽ سسٽم وسيلن جي گهٽ ۾ گهٽ استعمال سان.

اهو هڪ سنيپ شاٽ جي باري ۾ نه آهي سڄي سسٽم جي جلدي بحالي لاء، پر فائلن ۽ ڊيٽابيس ۽ تبديلين جي تاريخ بابت.

شروعاتي ڊيٽا:

VDS تي XEN ورچوئلائيزيشن؛
او ايس CentOS 7؛
1C-Bitrix: ويب ماحول؛
سائيٽ جي بنياد تي "1C-Bitrix: سائيٽ مينيجمينٽ"، معياري نسخو؛
فائل سائيز 50 GB آهي ۽ وڌندي ويندي؛
ڊيٽابيس جي سائيز 3 GB آهي ۽ وڌندي ويندي.

1C-Bitrix ۾ ٺهيل معياري بيڪ اپ - فوري طور تي خارج ٿيل. اهو صرف ننڍن سائيٽن لاء مناسب آهي، ڇاڪاڻ ته:

هر دفعي سائيٽ جي مڪمل ڪاپي ٺاهيندي، ترتيب سان، هر ڪاپي وڌيڪ جاء وٺندي جيئن آئون فائلون کڻان، منهنجي صورت ۾ اهو 50 GB آهي.
بيڪ اپ PHP استعمال ڪندي ڪيو ويندو آهي، جيڪو فائلن جي اهڙي مقدار سان ناممڪن آهي، اهو سرور کي اوورلوڊ ڪندو ۽ ڪڏهن به ختم نه ٿيندو.
۽ يقينن، مڪمل ڪاپي محفوظ ڪرڻ وقت ڪنهن به 90 ڏينهن جي ڳالهه نه ٿي سگهي.

اهو حل جيڪو ميزبان پيش ڪري ٿو هڪ بيڪ اپ ڊسڪ آهي ساڳئي ڊيٽا سينٽر ۾ VDS، پر هڪ مختلف سرور تي. توهان FTP ذريعي ڊسڪ سان ڪم ڪري سگهو ٿا ۽ پنهنجون اسڪرپٽ استعمال ڪري سگهو ٿا، يا جيڪڏهن ISPManager VDS تي انسٽال ٿيل آهي ته پوءِ ان جي بيڪ اپ ماڊل ذريعي. هي اختيار مناسب ناهي، ساڳئي ڊيٽا سينٽر جي استعمال جي ڪري.

مٿين سڀني مان، مون لاء بهترين انتخاب هڪ واڌارو بيڪ اپ آهي منهنجي پنهنجي صورتحال جي مطابق Yandex.Cloud (Object Storage) يا Amazon S3 (Amazon Simple Storage Service).

هن جي ضرورت آهي:

VDS تائين روٽ رسائي؛
نصب ٿيل ورجائي افاديت؛
Yandex.Cloud ۾ اڪائونٽ.

وڌندڙ بيڪ اپ - ھڪڙو طريقو جنھن ۾ صرف ڊيٽا جيڪا تبديل ٿي وئي آھي آخري بيڪ اپ کان محفوظ ٿيل آھي.

ڪٽيو - هڪ بيڪ اپ يوٽيلٽي جيڪا استعمال ڪري ٿي rsync الگورتھم ۽ ڪم ڪري سگھي ٿي Amazon S3 سان.

Yandex.Cloud بمقابلہ Amazon S3

مون لاء هن معاملي ۾ Yandex.Cloud ۽ Amazon S3 جي وچ ۾ ڪوبه فرق ناهي. Yandex Amazon S3 API جي مکيه حصي کي سپورٽ ڪري ٿو، تنهنڪري توهان ان سان ڪم ڪري سگهو ٿا حل استعمال ڪندي جيڪي S3 سان ڪم ڪرڻ لاءِ موجود آهن. منهنجي حالت ۾، هي نقل جي افاديت آهي.

Yandex جو بنيادي فائدو روبل ۾ ادائگي ٿي سگهي ٿو، جيڪڏهن اتي تمام گهڻو ڊيٽا آهي، ته پوء ڪو به لنڪ نه هوندو ڪورس سان. رفتار جي لحاظ کان، Amazon جا يورپي ڊيٽا سينٽر ڪم ڪن ٿا روسين سان گڏ Yandex ۾، مثال طور، توهان استعمال ڪري سگهو ٿا فرانڪفرٽ. مون اڳ ۾ استعمال ڪيو Amazon S3 ساڳئي ڪمن لاء، هاڻي مون فيصلو ڪيو Yandex جي ڪوشش ڪرڻ.

Yandex.Cloud ترتيب ڏيڻ

1. توهان کي Yandex.Cloud ۾ هڪ بلنگ اڪائونٽ ٺاهڻ جي ضرورت آهي. هن کي ڪرڻ لاء، توهان کي Yandex.Cloud ۾ لاگ ان ٿيڻ جي ضرورت آهي توهان جي Yandex اڪائونٽ ذريعي يا هڪ نئون ٺاهيو.

2. Cloud ٺاهيو.

3. "Cloud" ۾ هڪ "Catalog" ٺاهيو.

4. "Catalogue" لاءِ "Service Account" ٺاھيو.

5. "سروس اڪائونٽ" لاء ڪيچ ٺاهيو.

6. ڪنجيون محفوظ ڪريو، توھان کي مستقبل ۾ انھن جي ضرورت پوندي.

7. "Catalog" لاءِ "Bucket" ٺاھيو، فائلون ان ۾ پئجي وينديون.

8. مان هڪ حد مقرر ڪرڻ جي صلاح ڏيان ٿو ۽ "ڪولڊ اسٽوريج" چونڊيو.

سرور تي مقرر ڪيل بيڪ اپ سيٽنگ

هي گائيڊ بنيادي انتظامي صلاحيتن کي فرض ڪري ٿو.

1. VDS تي نقل جي افاديت کي انسٽال ڪريو

yum install duplicity

2. 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. پهريون ڀيرو اسڪرپٽ کي هلايو ۽ نتيجو چيڪ ڪريو، فائلون بالٽ ۾ ظاهر ٿيڻ گهرجن.

`which bash` /backup_scripts/backup.sh

5. روٽ استعمال ڪندڙ لاءِ ڪرون لاءِ اسڪرپٽ شامل ڪريو ڏينھن ۾ 2 ڀيرا، يا جيترو توھان کي ضرورت آھي.

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

Yandex.Cloud کان ڊيٽا واپس آڻڻ

1. بحال ڪريو فولڊر /backup_restore

2. بش بحال اسڪرپٽ ٺاهيو /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 فائل ملندي جيڪا اڳ ۾ بيڪ اپ ۾ شامل هئي.

توھان پنھنجي ضرورتن کي پورو ڪرڻ لاءِ بھترين ترميمون ڪري سگھو ٿا.

مائنس ٻيڻو

نقل ۾ هڪ خرابي آهي - چينل جي استعمال جي حد مقرر ڪرڻ جو ڪو طريقو ناهي. هڪ عام چينل سان، اهو مسئلو پيدا نٿو ڪري، پر هڪ DDoS-محفوظ چينل سان رفتار في ڏينهن جي بلنگ سان، مان 1-2 ميگاابٽ جي حد مقرر ڪرڻ جي قابل ٿيڻ چاهيان ٿو.

نتيجي طور

Yandex.Cloud يا Amazon S3 ۾ بيڪ اپ سائيٽ ۽ OS سيٽنگن جي هڪ آزاد ڪاپي مهيا ڪري ٿي جيڪا ڪنهن ٻئي سرور يا مقامي ڪمپيوٽر تان رسائي سگهجي ٿي. ساڳئي وقت، هي ڪاپي نظر نه ايندي آهي يا ته هوسٽنگ ڪنٽرول پينل ۾ يا Bitrix منتظم پينل ۾، جيڪا اضافي سيڪيورٽي فراهم ڪري ٿي.

سڀ کان وڌيڪ بدقسمتي جي نتيجي ۾، توهان هڪ نئون سرور ٺاهي سگهو ٿا ۽ سائيٽ کي ڪنهن به تاريخ لاء ترتيب ڏئي سگهو ٿا. جيتوڻيڪ سڀ کان وڌيڪ گهربل ڪارڪردگي هڪ مخصوص تاريخ لاء فائل تائين رسائي جي صلاحيت هوندي.

توهان هن ٽيڪنڪ کي ڪنهن به انجن تي ڪنهن به VDS يا وقف ٿيل سرور ۽ سائيٽن سان استعمال ڪري سگهو ٿا، نه رڳو 1C-Bitrix. او ايس پڻ ٿي سگهي ٿو CentOS کان سواء، جهڙوڪ Ubuntu يا Debian.

جو ذريعو: www.habr.com

Yandex.Cloud ۾ 1C-Bitrix تي سائيٽ سان وڌندڙ VDS بيڪ اپ

Yandex.Cloud بمقابلہ Amazon S3

Yandex.Cloud ترتيب ڏيڻ

سرور تي مقرر ڪيل بيڪ اپ سيٽنگ

Yandex.Cloud کان ڊيٽا واپس آڻڻ

نتيجي طور

تبصرو شامل ڪريو جواب منسوخ