Mən gündə iki dəfə “2C-Bitrix: Site Management” (fayllar və mysql verilənlər bazası) üzrə saytın ehtiyat nüsxəsini çıxarmalı və 1 gün ərzində dəyişikliklər tarixini saxlamalı idim.
Sayt 7C-Bitrix: Web Environment quraşdırılmış CentOS 1 ƏS ilə işləyən VDS-də yerləşir. Bundan əlavə, OS parametrlərinizin ehtiyat nüsxəsini çıxarın.
tələblər:
- Tezlik - gündə 2 dəfə;
- Nüsxələri son 90 gün ərzində saxlayın;
- Lazım gələrsə, müəyyən bir tarix üçün fərdi faylları əldə etmək imkanı;
- Yedək VDS-dən başqa məlumat mərkəzində saxlanmalıdır;
- İstənilən yerdən ehtiyat nüsxəyə daxil olmaq imkanı (başqa server, yerli kompüter və s.).
Əhəmiyyətli bir məqam əlavə yer və sistem resurslarının minimal istehlakı ilə ehtiyat nüsxələrini tez bir zamanda yaratmaq imkanı idi.
Bu, bütün sistemi tez bir zamanda bərpa etmək üçün bir şəkil haqqında deyil, fayllar və verilənlər bazası və dəyişikliklərin tarixi haqqındadır.
Başlanğıc:
- XEN virtualizasiyası üzrə VDS;
- ƏS CentOS 7;
- 1C-Bitrix: Veb mühiti;
- “1C-Bitrix: Saytın İdarə Edilməsi” əsasında vebsayt, Standart versiya;
- Faylın ölçüsü 50 GB-dır və artacaq;
- Verilənlər bazası ölçüsü 3 GB-dır və artacaq.
1C-Bitrix-də quraşdırılmış standart ehtiyat nüsxəsini dərhal xaric etdim. Yalnız kiçik saytlar üçün uyğundur, çünki:
- O, hər dəfə saytın tam surətini çıxarır, ona görə də hər nüsxə faylların tutduğu qədər yer tutacaq, mənim vəziyyətimdə 50 GB-dır.
- Yedəkləmə PHP-dən istifadə etməklə həyata keçirilir, bu, belə həcmli fayllarla mümkün deyil, serveri həddən artıq yükləyəcək və heç vaxt bitməyəcək.
- Və təbii ki, tam nüsxəni saxlayarkən hər hansı 90 gündən söhbət gedə bilməz.
Hosterin təklif etdiyi həll VDS ilə eyni məlumat mərkəzində, lakin fərqli serverdə yerləşən ehtiyat diskdir. Siz FTP vasitəsilə disklə işləyə və öz skriptlərinizdən istifadə edə bilərsiniz və ya ISPManager VDS-də quraşdırılıbsa, onun ehtiyat modulu vasitəsilə. Eyni məlumat mərkəzinin istifadəsi səbəbindən bu seçim uyğun deyil.
Yuxarıda göstərilənlərin hamısından mənim üçün ən yaxşı seçim Yandex.Cloud (Obyekt Yaddaşı) və ya Amazon S3-də (Amazon Simple Storage Service) öz skriptimdən istifadə edərək artan ehtiyat nüsxəsidir.
Bunun üçün tələb olunur:
- VDS-ə kök girişi;
- quraşdırılmış ikiqat yardım proqramı;
- Yandex.Cloud-da hesab.
Artan ehtiyat — yalnız sonuncu ehtiyat nüsxədən sonra dəyişmiş məlumatların arxivləşdirildiyi üsul.
ikiqatlıq — rsync alqoritmlərindən istifadə edən və Amazon S3 ilə işləyə bilən ehtiyat yardım proqramı.
Yandex.Cloud və Amazon S3
Bu halda mənim üçün Yandex.Cloud və Amazon S3 arasında heç bir fərq yoxdur. Yandex Amazon S3 API-nin əsas hissəsini dəstəkləyir, ona görə də S3 ilə işləmək üçün mövcud olan həllərdən istifadə edərək onunla işləyə bilərsiniz. Mənim vəziyyətimdə bu, ikiqat yardım proqramıdır.
Yandex-in əsas üstünlüyü rublla ödəniş ola bilər, əgər çox məlumat varsa, məzənnə ilə əlaqə olmayacaq. Sürət baxımından Amazon-un Avropa məlumat mərkəzləri Yandex-dəki Rusiya məlumat mərkəzləri ilə müqayisə edilə bilər; məsələn, Frankfurtdan istifadə edə bilərsiniz. Mən əvvəllər oxşar vəzifələr üçün Amazon S3-dən istifadə etdim, indi Yandex-i sınamaq qərarına gəldim.
Yandex.Cloud-un qurulması
1. Yandex.Cloud-da ödəniş hesabı yaratmalısınız. Bunu etmək üçün siz Yandex hesabınız vasitəsilə Yandex.Cloud-a daxil olmalısınız və ya yenisini yaratmalısınız.
2. "Bulud" yaradın.
3. "Bulud" da "Kataloq" yaradın.
4. "Kataloq" üçün "Xidmət hesabı" yaradın.
5. "Xidmət Hesabı" üçün açarlar yaradın.
6. Açarları saxla, gələcəkdə onlara lazım olacaq.
7. "Kataloq" üçün "Vedrə" yaradın, fayllar ona daxil olacaq.
8. Mən limit qoymağı və “Soyuq anbar”ı seçməyi məsləhət görürəm.
Serverdə planlaşdırılmış ehtiyat nüsxələrinin qurulması
Bu təlimat əsas idarəetmə bacarıqlarını nəzərdə tutur.
1. VDS-də ikiqat yardım proqramını quraşdırın
yum install duplicity2. MySQL zibilləri üçün bir qovluq yaradın, mənim vəziyyətimdə bu VDS kökündə /backup_db-dir
3. Bash skriptləri /backup_scripts üçün bir qovluq yaradın və ehtiyat nüsxələri yerinə yetirəcək ilk skripti yaradın /backup_scripts/backup.sh
Skript məzmunu:
#!`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;
fi4. Skripti ilk dəfə işə salın və nəticəni yoxlayın, fayllar “Bucket”də görünməlidir.
`which bash` /backup_scripts/backup.sh
5. Kök istifadəçinin gündə 2 dəfə və ya sizə lazım olan tezlikdə işləməsi üçün cron-a skript əlavə edin.
10 4,16 * * * `which bash` /backup_scripts/backup.shYandex.Cloud-dan məlumatların bərpası
1. Bərpa qovluğu yaradın /backup_restore
2. Bərpa /backup_scripts/restore.sh üçün bash skripti yaradın
Müəyyən bir faylı bərpa etməyin ən məşhur nümunəsini verirəm:
#!`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_KEY3. Skripti işə salın və nəticəni gözləyin.
`which bash` /backup_scripts/backup.sh/backup_restore/ qovluğunda siz əvvəllər ehtiyat nüsxəsi alınmış index.php faylını tapa bilərsiniz.
Ehtiyaclarınıza uyğun olaraq daha incə düzəlişlər edə bilərsiniz.
Mənfi təkrarlama
ikililiyin bir çatışmazlığı var - kanaldan istifadə limitini təyin etmək mümkün deyil. Adi bir kanalla bu problem yaratmır, lakin gündə sürətli şarj ilə DDoS ilə qorunan kanaldan istifadə edərkən mən 1-2 meqabit limit təyin etmək istərdim.
Nəticə olaraq
Yandex.Cloud və ya Amazon S3-də ehtiyat nüsxə hər hansı digər serverdən və ya yerli kompüterdən əldə edilə bilən saytın və OS parametrlərinin müstəqil surətini təmin edir. Üstəlik, bu nüsxə nə hostinq idarəetmə panelində, nə də əlavə təhlükəsizlik təmin edən Bitrix admin panelində görünmür.
Ən pis vəziyyətdə, siz yeni bir server toplaya və istənilən vaxt saytı yerləşdirə bilərsiniz. Baxmayaraq ki, ən populyar funksionallıq müəyyən bir tarix üçün fayla daxil olmaq imkanı olacaq.
Bu texnikadan yalnız 1C-Bitrix deyil, hər hansı VDS və ya Dedicated serverlər və istənilən mühərriklərdəki saytlarla istifadə edə bilərsiniz. ƏS həmçinin Ubuntu və ya Debian kimi CentOS-dan başqa ola bilər.
Mənbə: www.habr.com