ProHoster > Блог > Pagdumala > Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

Kinahanglan kong maghimo og mga backup sa site sa "2C-Bitrix: Site Management" (mga file ug mysql database) kaduha sa usa ka adlaw ug magtipig og kasaysayan sa mga kausaban sulod sa 1 ka adlaw.

Ang site nahimutang sa usa ka VDS nga nagpadagan sa CentOS 7 OS nga adunay 1C-Bitrix: Web Environment nga na-install. Dugang pa, paghimo og backup nga kopya sa imong mga setting sa OS.

Mga kinahanglanon:

  • Frequency - 2 beses sa usa ka adlaw;
  • Pagtipig og mga kopya sa katapusang 90 ka adlaw;
  • Ang abilidad sa pagkuha sa indibidwal nga mga file alang sa usa ka piho nga petsa, kon gikinahanglan;
  • Ang backup kinahanglang tipigan sa data center gawas sa VDS;
  • Ang abilidad sa pag-access sa backup gikan sa bisan asa (laing server, lokal nga kompyuter, ug uban pa).

Ang usa ka hinungdanon nga punto mao ang abilidad sa dali nga paghimo og mga backup nga adunay gamay nga pagkonsumo sa dugang nga wanang ug mga kapanguhaan sa sistema.

Dili kini bahin sa usa ka snapshot alang sa dali nga pagpahiuli sa tibuuk nga sistema, apan bahin sa mga file ug database ug ang kasaysayan sa pagbag-o.

Inisyal nga datos:

  • VDS sa XEN virtualization;
  • OS CentOS 7;
  • 1C-Bitrix: Web environment;
  • Website base sa "1C-Bitrix: Site Management", Standard nga bersyon;
  • Ang gidak-on sa file 50 GB ug motubo;
  • Ang gidak-on sa database mao ang 3 GB ug motubo.

Gisalikway dayon nako ang standard backup nga gitukod sa 1C-Bitrix. Kini angayan lamang alang sa gagmay nga mga site, tungod kay:

  • Kini naghimo sa usa ka bug-os nga kopya sa site sa matag higayon, mao nga ang matag kopya mokuha sa sama nga gidaghanon sa mga luna ingon nga ang mga file gikuha, sa akong kaso kini mao ang 50 GB.
  • Ang pag-backup gihimo gamit ang PHP, nga imposible sa ingon nga gidaghanon sa mga file, kini mag-overload sa server ug dili na mahuman.
  • Ug siyempre, wala’y mahimo nga hisgutan ang bisan unsang 90 ka adlaw kung magtipig usa ka tibuuk nga kopya.

Ang solusyon nga nagtanyag tig-hostKini usa ka backup disk nga nahimutang sa parehas nga data center sama sa VDS, apan sa lahi nga server. Mahimo nimong ma-access ang disk pinaagi sa FTP ug magamit ang imong kaugalingon nga mga script, o, kung ang ISPManager na-install sa VDS, pinaagi sa backup module niini. Kini nga kapilian dili angay tungod kay kini naggamit sa parehas nga data center.

Gikan sa tanan sa ibabaw, ang pinakamaayo nga pagpili alang kanako mao ang usa ka incremental backup gamit ang akong kaugalingong script sa Yandex.Cloud (Object Storage) o Amazon S3 (Amazon Simple Storage Service).

Kini nagkinahanglan:

  • gamut access sa VDS;
  • gi-install nga duplicity utility;
  • account sa Yandex.Cloud.

Dugang nga backup — usa ka paagi diin ang datos ra nga nabag-o sukad sa katapusan nga backup ang gi-archive.

pagkalimbong - usa ka backup nga gamit nga naggamit sa mga algorithm sa rsync ug mahimong magamit sa Amazon S3.

Yandex.Cloud batok sa Amazon S3

Sa kini nga kaso, walay kalainan tali sa Yandex.Cloud ug Amazon S3 alang kanako. Gisuportahan sa Yandex ang kadaghanan sa Amazon S3 API, aron makatrabaho ka niini gamit ang mga solusyon nga naglungtad alang sa pagtrabaho kauban ang S3. Sa akong kaso, kini ang duplicity utility.

Ang nag-unang bentaha sa Yandex mahimong pagbayad sa mga rubles, kung adunay daghang mga datos, nan wala’y link sa kurso. Sa mga termino sa katulin, ang mga sentro sa datos sa Europe sa Amazon nagtrabaho nga katumbas sa mga Ruso sa Yandex, pananglitan, mahimo nimong gamiton ang Frankfurt. Gigamit nako kaniadto ang Amazon S3 alang sa parehas nga mga buluhaton, karon nakahukom ko nga sulayan ang Yandex.

Pag-set up sa Yandex.Cloud

1. Kinahanglan ka nga maghimo usa ka account sa pagbayad sa Yandex.Cloud. Aron mahimo kini, kinahanglan ka nga mag-log in sa Yandex.Cloud pinaagi sa imong Yandex account o maghimo usa ka bag-o.

2. Paghimo og "Cloud".
Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

3. Sa "Cloud" paghimo og "Catalogue".
Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

4. Alang sa "Catalogue" paghimo usa ka "Serbisyo account".
Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

5. Paghimo og mga yawe alang sa "Serbisyo Account".
Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

6. I-save ang mga yawe, kini gikinahanglan sa umaabot.
Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

7. Alang sa "Directory" paghimo og "Bucket", ang mga file moadto niini.
Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

8. Girekomendar nako ang pagbutang og limitasyon ug pagpili sa "Cold Storage".
Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

Pag-set up sa naka-iskedyul nga pag-backup sa server

Kini nga giya adunay sukaranan nga kahanas sa pagdumala.

1. I-install ang duplicity utility sa VDS

yum install duplicity

2. Paghimo og usa ka folder alang sa mysql dumps, sa akong kaso kini mao ang /backup_db sa VDS gamut

3. Paghimo og folder alang sa bash scripts /backup_scripts ug himoa ang unang script nga mag-backup /backup_scripts/backup.sh

Mga sulod sa script:

#!`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. Pagdalagan ang script sa unang higayon ug susiha ang resulta, ang mga file kinahanglan nga makita sa Balde.

`which bash` /backup_scripts/backup.sh

Incremental VDS backup nga adunay usa ka site sa 1C-Bitrix sa Yandex.Cloud

5. Pagdugang og script sa cron para sa root user nga modagan 2 beses sa usa ka adlaw, o sa frequency nga imong gikinahanglan.

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

Pagbawi sa datos gikan sa Yandex.Cloud

1. Paghimo og restore folder /backup_restore

2. Paghimo ug bash script para sa recovery /backup_scripts/restore.sh

Gihatag nako ang labing inila nga pananglitan sa pagpahiuli sa usa ka piho nga file:

#!`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. Pagdalagan ang script ug paghulat sa resulta.

`which bash` /backup_scripts/backup.sh

Sa /backup_restore/ folder makita nimo ang index.php file nga gi-back up kaniadto.

Makahimo ka og mas maayo nga mga pagbag-o nga mohaum sa imong mga panginahanglan.

minus pagdoble

Ang pagdoble adunay usa ka disbentaha - dili posible nga magtakda og limitasyon sa paggamit sa channel. Sa usa ka regular nga channel dili kini makamugna og problema, apan kung naggamit sa usa ka channel nga gipanalipdan sa DDoS nga adunay tulin nga pag-charge kada adlaw, gusto nako nga makahimo og limitasyon sa 1-2 megabits.

Ingong konklusyon

Ang pag-backup sa Yandex.Cloud o Amazon S3 makahatag og independente nga kopya sa imong website ug mga setting sa OS nga ma-access gikan sa bisan unsang laing server o lokal nga kompyuter. Kini nga kopya dili makita ni bisan kinsa. control panel hosting, ni sa Bitrix admin panel, nga naghatag og dugang seguridad.

Sa pinakagrabe nga senaryo sa kaso, mahimo kang mag-assemble og bag-ong server ug i-deploy ang site sa bisan unsang petsa. Bisan kung ang labing inila nga gamit mao ang abilidad sa pag-access sa usa ka file alang sa usa ka piho nga petsa.

Mahimo nimong gamiton kini nga teknik sa bisan unsang VDS o Dedicated server ug site sa bisan unsang makina, dili lang sa 1C-Bitrix. Ang OS mahimo usab nga lain sa CentOS, sama sa Ubuntu o Debian.

Source: www.habr.com