Ավելացվող VDS-ի կրկնօրինակում 1C-Bitrix կայքի միջոցով Yandex.Cloud-ում

Ինձ համար անհրաժեշտ էր օրական 2 անգամ կրկնօրինակել կայքը 1C-Bitrix: Site Management-ում (ֆայլեր և mysql տվյալների բազա) և պահել փոփոխությունների պատմությունը 90 օրվա ընթացքում:

Կայքը գտնվում է VDS-ի վրա, որն աշխատում է CentOS 7-ով, որտեղ տեղադրված է «1C-Bitrix: Web Environment»: Բացի այդ, OS-ի կարգավորումների կրկնօրինակ պատճենեք:

պահանջները:

• Հաճախականությունը - օրական 2 անգամ;
• Պահպանեք պատճենները վերջին 90 օրվա ընթացքում;
• Անհրաժեշտության դեպքում, որոշակի ամսաթվի համար առանձին ֆայլեր ստանալու ունակություն.
• Կրկնօրինակը պետք է պահվի VDS-ից տարբեր տվյալների կենտրոնում.
• Ցանկացած վայրից (այլ սերվեր, տեղական համակարգիչ և այլն) կրկնօրինակում մուտք գործելու հնարավորություն:

Կարևոր կետը լրացուցիչ տարածքի և համակարգի ռեսուրսների նվազագույն սպառմամբ կրկնօրինակներ արագ ստեղծելու ունակությունն էր:

Խոսքը ոչ թե ամբողջ համակարգի արագ վերականգնման համար նկարի մասին է, այլ ֆայլերի և տվյալների բազայի և փոփոխությունների պատմության մասին:

Նախնական տվյալներ.

• VDS XEN վիրտուալացման վրա;
• OS CentOS 7;
• 1C-Bitrix. Վեբ միջավայր;
• Կայքը հիմնված է «1C-Bitrix. Site Management», Ստանդարտ տարբերակ;
• Ֆայլի չափը 50 ԳԲ է և կաճի;
• Տվյալների բազայի չափը 3 ԳԲ է և կաճի։

1C-Bitrix-ում ներկառուցված ստանդարտ կրկնօրինակում - անմիջապես բացառվում է: Այն հարմար է միայն փոքր կայքերի համար, քանի որ.

• Ամեն անգամ կատարում է կայքի ամբողջական պատճենը, համապատասխանաբար, յուրաքանչյուր պատճենը կզբաղեցնի այնքան տեղ, որքան ես կզբաղեցնեմ ֆայլերը, իմ դեպքում դա 50 ԳԲ է։
• Կրկնօրինակումը կատարվում է PHP-ի միջոցով, ինչը անհնար է ֆայլերի նման ծավալների դեպքում, այն կծանրաբեռնի սերվերը և երբեք չի ավարտվի։
• Եվ իհարկե, ամբողջական օրինակը պահելու ժամանակ որևէ 90 օրվա մասին խոսք լինել չի կարող։

Լուծումը, որն առաջարկում է հոսթերը, պահուստային սկավառակ է, որը գտնվում է նույն տվյալների կենտրոնում, ինչ VDS-ը, բայց այլ սերվերի վրա: Դուք կարող եք սկավառակի հետ աշխատել FTP-ի միջոցով և օգտագործել ձեր սեփական սկրիպտները, կամ եթե ISPManager-ը տեղադրված է VDS-ում, ապա դրա պահեստային մոդուլի միջոցով: Այս տարբերակը հարմար չէ նույն տվյալների կենտրոնի օգտագործման պատճառով:

Վերոնշյալ բոլորից, ինձ համար լավագույն ընտրությունը լրացուցիչ կրկնօրինակումն է՝ ըստ իմ սցենարի Yandex.Cloud-ում (Օբյեկտների պահեստավորում) կամ Amazon S3-ում (Amazon Simple Storage Service):

Սա պահանջում է.

• արմատային մուտք դեպի VDS;
• տեղադրված duplicity կոմունալ;
• հաշիվ Yandex.Cloud-ում:

աստիճանական կրկնօրինակում - մեթոդ, որում արխիվացվում են միայն վերջին պահուստավորումից հետո փոխված տվյալները:

կրկնությունը - կրկնօրինակի օգտակար ծրագիր, որն օգտագործում է rsync ալգորիթմներ և կարող է աշխատել Amazon S3-ի հետ:

Yandex.Cloud vs 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. Ստեղծեք ամպ:


3. «Cloud»-ում ստեղծեք «Կատալոգ»:


4. «Կատալոգի» համար ստեղծեք «Ծառայության հաշիվ»:


5. «Ծառայության հաշվի» համար ստեղծեք բանալիներ:


6. Պահեք բանալիները, դրանք ձեզ պետք կգան ապագայում։


7. «Կատալոգի» համար ստեղծեք «Դույլ», ֆայլերը կընկնեն դրա մեջ:


8. Խորհուրդ եմ տալիս սահմանաչափ դնել և ընտրել «Սառը պահեստավորում»:

Սերվերի վրա պլանավորված կրկնօրինակների տեղադրում

Այս ուղեցույցը ենթադրում է հիմնական վարչական հմտություններ:

1. Տեղադրեք duplicity կոմունալ ծրագիրը VDS-ի վրա

yum install duplicity

2. Ստեղծեք թղթապանակ mysql dumps-ի համար, իմ դեպքում դա /backup_db է VDS արմատում

3. Ստեղծեք թղթապանակ bash scripts /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 ֆայլը, որը նախկինում ներառված էր կրկնօրինակում:

Դուք կարող եք ավելի նուրբ ճշգրտումներ կատարել ձեր կարիքներին համապատասխան:

մինուս երկակիությունը

Կրկնակիությունը մեկ թերություն ունի՝ ալիքի օգտագործման սահմանափակում սահմանելու հնարավորություն չկա: Նորմալ ալիքով սա խնդիր չի ստեղծում, բայց DDoS-ով պաշտպանված ալիքով՝ օրական վճարման արագությամբ, ես կցանկանայի, որ կարողանայի սահմանել 1-2 մեգաբիթ:

Որպես եզրակացություն

Yandex.Cloud-ում կամ Amazon S3-ում պահուստավորումը ապահովում է կայքի և ՕՀ-ի կարգավորումների անկախ պատճենը, որը հասանելի է ցանկացած այլ սերվերից կամ տեղական համակարգչից: Միևնույն ժամանակ, այս պատճենը տեսանելի չէ ոչ հոստինգի կառավարման վահանակում, ոչ էլ Bitrix-ի ադմինիստրատորի վահանակում, որն ապահովում է լրացուցիչ անվտանգություն։

Ամենադժբախտ արդյունքի դեպքում դուք կարող եք կառուցել նոր սերվեր և տեղակայել կայքը ցանկացած ամսաթվի համար: Թեև ամենաշատ պահանջվող գործառույթը կլինի ֆայլը որոշակի ամսաթվի մուտք գործելու հնարավորությունը:

Դուք կարող եք օգտագործել այս տեխնիկան ցանկացած VDS կամ հատուկ սերվերների և կայքերի հետ ցանկացած շարժիչի վրա, ոչ միայն 1C-Bitrix: ՕՀ-ը կարող է լինել նաև CentOS-ից բացի, օրինակ՝ Ubuntu-ն կամ Debian-ը:

Source: www.habr.com