Min hewce kir ku rojê du caran li ser "2C-Bitrix: Rêvebiriya Malperê" (pelan û databasa mysql) ji malperê paşvekêşan çêkim û 1 rojan dîroka guhertinan hilînim.
Malper li ser VDS-ya ku CentOS 7 OS-ya ku 1C-Bitrix: Jîngehek Web-ê hatî saz kirin dimeşîne ye. Wekî din, kopiyek hilanînê ya mîhengên OS-ya xwe çêbikin.
Hewce:
- Frequency - rojê 2 caran;
- Kopiyên 90 rojên dawîn biparêzin;
- Ger hewce be, şiyana bidestxistina pelên kesane ji bo tarîxek taybetî;
- Pêdivî ye ku hilanînê ji bilî VDS li navendek daneyê were hilanîn;
- Kapasîteya gihîştina hilanînê ji her deverê (pêşvekerek din, komputerek herêmî, hwd.).
Xalek girîng ew bû ku meriv zû paşvekêşan bi karanîna hindiktirîn cîh û çavkaniyên pergalê re biafirîne.
Ev ne li ser wêneyek ji bo sererastkirina bilez a tevahî pergalê ye, lê di derbarê pelan û databasê û dîroka guhertinan de ye.
Daneyên destpêkê:
- VDS li ser virtualîzasyona XEN;
- OS CentOS 7;
- 1C-Bitrix: hawîrdora malperê;
- Malpera li ser bingeha "1C-Bitrix: Rêveberiya Malperê", Guhertoya Standard;
- Mezinahiya pelê 50 GB ye û dê mezin bibe;
- Mezinahiya databasê 3 GB ye û dê mezin bibe.
Min tavilê paşgira standard a ku di 1C-Bitrix de hatî çêkirin ji holê rakir. Ew tenê ji bo malperên piçûk maqûl e, ji ber ku:
- Ew her carê kopiyek tam a malperê çêdike, ji ber vê yekê her kopî dê heman cîhê ku pelan digire bigire, di doza min de ew 50 GB ye.
- Backup bi karanîna PHP-ê tête kirin, ku bi vî rengî pelan ne gengaz e, ew ê serverê zêde bar bike û dê çu carî neqede.
- Û bê guman, dema ku kopiyek bêkêmasî tê hilanîn, 90 roj nayê axaftin.
Çareseriya ku pêşkêş dike mêvandarEv dîskek hilanînê ye ku di heman navenda daneyan a VDS-ê de ye, lê li ser serverek cûda ye. Hûn dikarin bi rêya FTP-ê bigihîjin dîskê û skrîptên xwe bikar bînin, an jî, heke ISPManager li ser VDS-ê sazkirî be, bi rêya modula wê ya hilanînê. Ev vebijark ne guncaw e ji ber ku ew heman navenda daneyan bikar tîne.
Ji van hemî jorîn, bijareya çêtirîn ji bo min hilbijarkek zêde ye ku bi karanîna skrîpta xwe ya li Yandex.Cloud (Storage Object) an Amazon S3 (Xizmeta Hilgirtina Hêsan a Amazon) bikar tîne.
Ev hewce dike:
- gihîştina root ya VDS;
- utility duplicity sazkirî;
- hesabê Yandex.Cloud.
Piştgiriya zêde - rêbazek ku tê de tenê daneyên ku ji paşvekêşana paşîn ve hatî guhertin têne arşîv kirin.
durûtî - amûrek hilanînê ku algorîtmayên rsync bikar tîne û dikare bi Amazon S3 re bixebite.
Yandex.Cloud vs Amazon S3
Di vê rewşê de, ji bo min di navbera Yandex.Cloud û Amazon S3 de cûdahî tune. Yandex piranîya Amazon S3 API-yê piştgirî dike, ji ber vê yekê hûn dikarin bi karanîna çareseriyên ku ji bo xebata bi S3 re hene bikar bînin. Di doza min de, ev kargêriya dubendiyê ye.
Feydeya sereke ya Yandex dibe ku dravdana bi rubleyê be, heke gelek dane hebin, dê ti girêdanek bi rêjeya danûstendinê re nebe. Di warê lezê de, navendên daneyên Ewropî yên Amazon-ê bi navendên daneya rûsî yên li Yandex-ê re dixebitin, mînakî, hûn dikarin Frankfurt bikar bînin. Min berê Amazon S3 ji bo karên wekhev bikar anî, naha min biryar da ku Yandex biceribînim.
Sazkirina Yandex.Cloud
1. Pêdivî ye ku hûn li Yandex.Cloud hesabek dravdanê biafirînin. Ji bo vê yekê, hûn hewce ne ku bi hesabê xwe ya Yandex-ê têkevin Yandex.Cloud an jî yekî nû biafirînin.
2. "Cloud" biafirînin.

3. Di "Cloud" de "Katalog" çêbikin.

4. Ji bo "Katalog" "Hesabê Xizmetê" çêbikin.

5. Ji bo "Hesabê Xizmetê" mifteyan biafirînin.

6. Bişkojkan biparêzin, ew ê di pêşerojê de hewce bibin.

7. Ji bo "Rêveber" "Bucket" biafirînin, pel dê têkevin wê.

8. Ez pêşniyar dikim ku sînorek saz bikin û "Storage Cold" hilbijêrin.

Sazkirina paşkêşên plansazkirî li ser serverê
Ev rêber jêhatîbûnên rêveberiyê yên bingehîn digire.
1. Li ser VDS-ê amûra dubendiyê saz bikin
yum install duplicity2. Peldankek ji bo peldankên mysql biafirînin, di doza min de ew /backup_db di koka VDS de ye
3. Peldankek ji bo nivîsarên bash /backup_scripts biafirînin û yekem skrîpta ku dê paşgiran pêk bîne çêbikin /backup_scripts/backup.sh
Naveroka nivîsê:
#!`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. Ji bo cara yekem skrîptê bimeşînin û encaman kontrol bikin divê di "Bucket"ê de xuya bibin.
`which bash` /backup_scripts/backup.sh
5. Ji bo bikarhênerê root skrîptek li cron zêde bikin ku rojê 2 caran, an jî bi frekansa ku hûn hewce ne.
10 4,16 * * * `which bash` /backup_scripts/backup.shVegerandina daneyan ji Yandex.Cloud
1. Peldankek başbûnê çêbikin /backup_restore
2. Ji bo hilanînê/backup_scripts/restore.sh skrîptek bash çêkin
Ez mînaka herî populer a sererastkirina pelek taybetî didim:
#!`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. Skrîptê bimeşînin û li benda encamê bisekinin.
`which bash` /backup_scripts/backup.shDi peldanka /backup_restore/ de hûn ê pelê index.php ku berê pişta xwe girtibû bibînin.
Hûn dikarin li gorî hewcedariyên xwe verastkirinên xweştir bikin.
Minus dubendî
dubendî yek kêmasiyek heye - ne gengaz e ku meriv sînorê karanîna kanalê destnîşan bike. Bi kanalek birêkûpêk re ev pirsgirêk dernakeve, lê dema ku kanalek DDoS-parastî ya bi barkirina leza rojane bikar tîne, ez dixwazim ku ez bikaribim sînorek 1-2 megabitan destnîşan bikim.
Wek encam
Vegerandina kopiyek li ser Yandex.Cloud an Amazon S3 kopiyek serbixwe ya malper û mîhengên OS-ya we peyda dike ku meriv dikare ji her serverek din an kompîturek herêmî bigihîje wê. Ev kopiya ji bo kesî nayê dîtin. panelên kontrolê hosting, ne jî di panela rêveberiya Bitrix de, ku ewlehiya zêde peyda dike.
Di senaryoya herî xirab de, hûn dikarin serverek nû berhev bikin û malperê di her tarîxê de bicîh bikin. Her çend fonksiyona herî populer dê şiyana gihîştina pelek ji bo tarîxek taybetî be.
Hûn dikarin vê teknîkê bi her server û malperan VDS an Dedicated bikar bînin, ne tenê 1C-Bitrix. Dibe ku OS ji bilî CentOS-ê, wekî Ubuntu an Debian, din jî be.
Source: www.habr.com
