დამატებითი VDS სარეზერვო ასლი საიტით 1C-Bitrix-ზე Yandex.Cloud-ში

საჭირო იყო საიტის სარეზერვო ასლი 2C-Bitrix: Site Management-ზე დღეში 1-ჯერ (ფაილები და mysql მონაცემთა ბაზა) და ცვლილებების ისტორიის შენახვა 90 დღის განმავლობაში.

საიტი მდებარეობს VDS-ზე, რომელიც მუშაობს CentOS 7-ზე და დაინსტალირებულია „1C-Bitrix: Web Environment“. გარდა ამისა, გააკეთეთ OS პარამეტრების სარეზერვო ასლი.

მოთხოვნები:

• სიხშირე - 2-ჯერ დღეში;
• შეინახეთ ასლები ბოლო 90 დღის განმავლობაში;
• საჭიროების შემთხვევაში, კონკრეტული თარიღისთვის ინდივიდუალური ფაილების მიღების შესაძლებლობა;
• სარეზერვო ასლი უნდა იყოს შენახული VDS-ის გარდა მონაცემთა ცენტრში;
• სარეზერვო ასლის წვდომის შესაძლებლობა ნებისმიერი ადგილიდან (სხვა სერვერი, ლოკალური კომპიუტერი და ა.შ.).

მნიშვნელოვანი პუნქტი იყო სარეზერვო ასლების სწრაფად შექმნის შესაძლებლობა დამატებითი სივრცისა და სისტემის რესურსების მინიმალური მოხმარებით.

ეს არ არის მთელი სისტემის სწრაფი აღდგენის სნეპშოტზე, არამედ ფაილებზე და მონაცემთა ბაზაზე და ცვლილებების ისტორიაზე.

საწყისი მონაცემები:

• VDS XEN ვირტუალიზაციაზე;
• OS CentOS 7;
• 1C-Bitrix: ვებ გარემო;
• საიტი დაფუძნებული "1C-Bitrix: საიტის მენეჯმენტი", სტანდარტული ვერსია;
• ფაილის ზომა არის 50 GB და გაიზრდება;
• მონაცემთა ბაზის ზომა არის 3 GB და გაიზრდება.

1C-Bitrix-ში ჩაშენებული სტანდარტული სარეზერვო ასლი - დაუყოვნებლივ გამოირიცხება. იგი განკუთვნილია მხოლოდ მცირე საიტებისთვის, რადგან:

• ყოველ ჯერზე აკეთებს საიტის სრულ ასლს, შესაბამისად, თითოეული ასლი დაიკავებს იმდენ ადგილს, რამდენსაც მე ვიკავებ ფაილებს, ჩემს შემთხვევაში ეს არის 50 გბ.
• სარეზერვო ასლის შექმნა ხდება PHP-ის გამოყენებით, რაც შეუძლებელია ფაილების ასეთი მოცულობით, ის გადატვირთავს სერვერს და არასოდეს დასრულდება.
• და რა თქმა უნდა, სრული ასლის შენახვისას 90 დღეზე საუბარი არ შეიძლება.

გამოსავალი, რომელსაც ჰოსტერი გვთავაზობს, არის სარეზერვო დისკი, რომელიც მდებარეობს იმავე მონაცემთა ცენტრში, როგორც VDS, მაგრამ სხვა სერვერზე. თქვენ შეგიძლიათ იმუშაოთ დისკთან FTP-ის საშუალებით და გამოიყენოთ თქვენი სკრიპტები, ან თუ ISPManager დაინსტალირებულია VDS-ზე, მაშინ მისი სარეზერვო მოდულის მეშვეობით. ეს ვარიანტი არ არის შესაფერისი იმავე მონაცემთა ცენტრის გამოყენების გამო.

ყოველივე ზემოთქმულიდან, ჩემთვის საუკეთესო არჩევანია დამატებითი სარეზერვო ასლი ჩემი საკუთარი სცენარის მიხედვით Yandex.Cloud-ში (ობიექტების შენახვა) ან Amazon S3-ში (Amazon Simple Storage Service).

ეს მოითხოვს:

• root წვდომა VDS-ზე;
• დაყენებული duplicity უტილიტა;
• ანგარიში Yandex.Cloud-ში.

დამატებითი სარეზერვო - მეთოდი, რომლის დროსაც არქივდება მხოლოდ მონაცემები, რომლებიც შეიცვალა ბოლო სარეზერვო ასლის შემდეგ.

გაორებისა - სარეზერვო პროგრამა, რომელიც იყენებს rsync ალგორითმებს და შეუძლია იმუშაოს Amazon S3-თან.

Yandex.Cloud vs Amazon S3

Yandex.Cloud-სა და Amazon S3-ს შორის ამ შემთხვევაში ჩემთვის არანაირი განსხვავება არ არის. Yandex მხარს უჭერს Amazon S3 API-ს ძირითად ნაწილს, ასე რომ თქვენ შეგიძლიათ მასთან მუშაობა S3-თან მუშაობისთვის ხელმისაწვდომი გადაწყვეტილებების გამოყენებით. ჩემს შემთხვევაში, ეს არის ორმაგი უტილიტა.

Yandex-ის მთავარი უპირატესობა შეიძლება იყოს გადახდა რუბლებში, თუ ბევრი მონაცემია, მაშინ კურსზე ბმული არ იქნება. სიჩქარის მხრივ, ამაზონის ევროპული მონაცემთა ცენტრები მუშაობენ რუსულის პროპორციულად Yandex-ში, მაგალითად, შეგიძლიათ გამოიყენოთ ფრანკფურტი. ადრე ვიყენებდი Amazon S3-ს მსგავსი ამოცანებისთვის, ახლა გადავწყვიტე Yandex ვცადო.

Yandex.Cloud-ის დაყენება

1. თქვენ უნდა შექმნათ ბილინგის ანგარიში Yandex.Cloud-ში. ამისათვის თქვენ უნდა შეხვიდეთ Yandex.Cloud-ში თქვენი Yandex ანგარიშის მეშვეობით ან შექმნათ ახალი.

2. Cloud-ის შექმნა.


3. "ღრუბელში" შექმენით "კატალოგი".


4. "კატალოგისთვის" შექმენით "სერვისის ანგარიში".


5. "სერვისის ანგარიშისთვის" შექმენით გასაღებები.


6. შეინახეთ გასაღებები, ისინი დაგჭირდებათ მომავალში.


7. "კატალოგისთვის" შექმენით "Bucket", ფაილები მოხვდება მასში.


8. გირჩევთ დააყენოთ ლიმიტი და აირჩიოთ „ცივი სათავსო“.

სერვერზე დაგეგმილი სარეზერვო ასლების დაყენება

ეს სახელმძღვანელო ითვალისწინებს ძირითად ადმინისტრაციულ უნარებს.

1. დააინსტალირეთ duplicity უტილიტა VDS-ზე

yum install duplicity

2. შექმენით საქაღალდე mysql dumps-ისთვის, ჩემს შემთხვევაში ეს არის /backup_db VDS root-ში

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-ს, რომ root მომხმარებელი შესრულდეს დღეში 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 ფაილს, რომელიც ადრე იყო ჩართული სარეზერვო ასლში.

თქვენ შეგიძლიათ გააკეთოთ უფრო ზუსტი კორექტირება თქვენი საჭიროებების შესაბამისად.

მინუს ორპირობა

ორმაგობას აქვს ერთი ნაკლი - არ არსებობს არხის გამოყენების ლიმიტის დაწესება. ნორმალური არხით ეს პრობლემას არ ქმნის, მაგრამ DDoS დაცული არხით დღეში სიჩქარით ბილინგით მინდა შევძლო 1-2 მეგაბიტის ლიმიტის დაყენება.

როგორც დასკვნა

Yandex.Cloud-ში ან Amazon S3-ში სარეზერვო ასლის შექმნა უზრუნველყოფს საიტის და OS-ის პარამეტრების დამოუკიდებელ ასლს, რომლის წვდომა შესაძლებელია ნებისმიერი სხვა სერვერიდან ან ლოკალური კომპიუტერიდან. ამავდროულად, ეს ასლი არ ჩანს არც ჰოსტინგის მართვის პანელში და არც Bitrix ადმინისტრაციულ პანელში, რაც უზრუნველყოფს დამატებით უსაფრთხოებას.

ყველაზე სამწუხარო შედეგით, შეგიძლიათ შექმნათ ახალი სერვერი და განათავსოთ საიტი ნებისმიერი თარიღისთვის. მიუხედავად იმისა, რომ ყველაზე მოთხოვნადი ფუნქცია იქნება ფაილზე წვდომის შესაძლებლობა კონკრეტული თარიღისთვის.

თქვენ შეგიძლიათ გამოიყენოთ ეს ტექნიკა ნებისმიერი VDS-ით ან გამოყოფილი სერვერებით და საიტებით ნებისმიერ ძრავზე, არა მხოლოდ 1C-Bitrix-ზე. OS ასევე შეიძლება იყოს CentOS-ის გარდა, როგორიცაა Ubuntu ან Debian.

წყარო: www.habr.com