Pliiga VDS-sekurkopio kun retejo sur 1C-Bitrix en Yandex.Cloud

Estis necese por mi sekurkopii la retejon al 2C-Bitrix: Reteja Administrado 1 fojojn tage (dosieroj kaj mysql-datumbazo) kaj konservi historion de ŝanĝoj dum 90 tagoj.

La retejo situas sur VDS funkcianta CentOS 7 kun "1C-Bitrix: Reteja Medio" instalita. Aldone, faru rezervan kopion de la OS-agordoj.

Postuloj:

• Ofteco - 2 fojojn tage;
• Konservu kopiojn dum la lastaj 90 tagoj;
• La kapablo akiri individuajn dosierojn por specifa dato, se necese;
• La sekurkopio devas esti konservita en datumcentro krom VDS;
• La kapablo aliri la sekurkopion de ie ajn (alia servilo, loka komputilo, ktp.).

Grava punkto estis la kapablo rapide krei sekurkopiojn kun minimuma konsumo de plia spaco kaj sistemaj rimedoj.

Ĉi tio ne temas pri momentfoto por rapida restarigo de la tuta sistemo, sed pri dosieroj kaj la datumbazo kaj la historio de ŝanĝoj.

Komencaj datumoj:

• VDS pri XEN-virtualigo;
• OS CentOS 7;
• 1C-Bitrix: Reta medio;
• Retejo bazita sur "1C-Bitrix: Site Management", Norma versio;
• La grandeco de dosiero estas 50 GB kaj kreskos;
• La datumbazo grandeco estas 3 GB kaj kreskos.

Norma sekurkopio konstruita en 1C-Bitrix - tuj ekskludita. Ĝi taŭgas nur por malgrandaj retejoj, ĉar:

• Faras kompletan kopion de la retejo ĉiufoje, respektive, ĉiu kopio okupos tiom da spaco kiom mi okupas la dosierojn, en mia kazo ĝi estas 50 GB.
• Rezervo estas farita per PHP, kio estas neebla kun tiaj volumoj de dosieroj, ĝi troŝarĝos la servilon kaj neniam finiĝos.
• Kaj kompreneble, oni ne povas paroli pri iuj 90 tagoj dum konservado de plena kopio.

La solvo, kiun proponas la gastiganto, estas rezerva disko situanta en la sama datumcentro kiel la VDS, sed sur malsama servilo. Vi povas labori kun la disko per FTP kaj uzi viajn proprajn skriptojn, aŭ se ISPManager estas instalita sur la VDS, tiam per ĝia rezerva modulo. Ĉi tiu opcio ne taŭgas pro la uzo de la sama datumcentro.

El ĉio ĉi-supra, la plej bona elekto por mi estas pliiga sekurkopio laŭ mia propra scenaro en Yandex.Cloud (Object Storage) aŭ Amazon S3 (Amazon Simpla Stokado-Servo).

Ĉi tio postulas:

• radika aliro al VDS;
• instalita duobla utileco;
• konto en Yandex.Cloud.

pliiga sekurkopio - metodo en kiu nur datumoj kiuj ŝanĝiĝis ekde la lasta sekurkopio estas arkivitaj.

duobligo - rezerva ilo, kiu uzas rsync-algoritmojn kaj povas funkcii kun Amazon S3.

Yandex.Cloud kontraŭ Amazon S3

Ne estas diferenco inter Yandex.Cloud kaj Amazon S3 ĉi-kaze por mi. Yandex subtenas la ĉefan parton de la Amazon S3 API, do vi povas labori kun ĝi uzante la solvojn disponeblajn por labori kun S3. En mia kazo, ĉi tiu estas la dupleca utileco.

La ĉefa avantaĝo de Yandex povas esti pago en rubloj, se estas multaj datumoj, tiam ne estos ligo al la kurso. Koncerne rapidecon, la eŭropaj datumcentroj de Amazon funkcias proporcie kun rusaj en Yandex, ekzemple, vi povas uzi Frankfurton. Mi antaŭe uzis Amazon S3 por similaj taskoj, nun mi decidis provi Yandex.

Agordi Yandex.Cloud

1. Vi devas krei fakturan konton en Yandex.Cloud. Por fari tion, vi devas ensaluti al Yandex.Cloud per via Yandex-konto aŭ krei novan.

2. Krei Nubon.


3. En la "Nubo" kreu "Katalogon".


4. Por la "Katalogo" kreu "Servan konton".


5. Por la "Serva konto" kreu ŝlosilojn.


6. Konservu la ŝlosilojn, vi bezonos ilin estonte.


7. Por la "Katalogo" kreu "Sitelon", dosieroj falos en ĝin.


8. Mi rekomendas agordi limon kaj elekti "Malvarma stokado".

Agordi planitajn sekurkopiojn sur la servilo

Ĉi tiu gvidilo supozas bazajn administrajn kapablojn.

1. Instalu la duoblan ilon sur la VDS

yum install duplicity

2. Kreu dosierujon por mysql rubejoj, en mia kazo ĝi estas /backup_db en la VDS-radiko

3. Kreu dosierujon por bash-skriptoj /backup_scripts kaj faru la unuan skripton, kiu rezervas /backup_scripts/backup.sh

Skriptenhavo:

#!`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. Rulu la skripton por la unua fojo kaj kontrolu la rezulton, dosieroj devus aperi en la Sitelo.

`which bash` /backup_scripts/backup.sh

5. Aldonu skripton al cron por ke la radika uzanto estu ekzekutita 2 fojojn tage, aŭ tiom ofte kiom vi bezonas.

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

Reakiro de datumoj de Yandex.Cloud

1. Faru reakivan dosierujon /backup_restore

2. Faru bash restore skripton /backup_scripts/restore.sh

Mi donas la plej petitan ekzemplon pri reakiro de specifa dosiero:

#!`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. Rulu la skripton kaj atendu la rezulton.

`which bash` /backup_scripts/backup.sh

En la dosierujo /backup_restore/ vi trovos la dosieron index.php, kiu antaŭe estis inkluzivita en la sekurkopio.

Vi povas fari pli bonajn ĝustigojn laŭ viaj bezonoj.

minus dupleco

Dupleco havas unu malavantaĝon - ne ekzistas maniero agordi limon de uzado de kanalo. Kun normala kanalo, tio ne kreas problemon, sed kun DDoS-protektita kanalo kun rapideco ĉiutage fakturado, mi ŝatus povi agordi limon de 1-2 megabitoj.

Kiel konkludo

Sekurkopio en Yandex.Cloud aŭ Amazon S3 provizas sendependan kopion de la retejo kaj OS-agordoj alireblaj de iu ajn alia servilo aŭ loka komputilo. Samtempe, ĉi tiu kopio ne videblas nek en la gastiga kontrolpanelo nek en la administra panelo Bitrix, kiu provizas plian sekurecon.

En la plej malfeliĉa rezulto, vi povas konstrui novan servilon kaj disfaldi la retejon por iu ajn dato. Kvankam la plej petita funkcio estos la kapablo aliri la dosieron por specifa dato.

Vi povas uzi ĉi tiun teknikon kun ajnaj VDS aŭ Dediĉaj serviloj kaj retejoj sur iuj motoroj, ne nur 1C-Bitrix. La VIN ankaŭ povas esti alia ol CentOS, kiel Ubuntu aŭ Debian.

fonto: www.habr.com