Pidin saidist kaks korda päevas varukoopia tegema saidile „2C-Bitrix: Site Management” (failid ja MySQL-i andmebaas) ning säilitama muudatuste ajalugu 1 päeva.
Sait asub VDS-il, millel töötab CentOS 7 ja millele on installitud "1C-Bitrix: Web Environment". Lisaks tehke operatsioonisüsteemi sätetest varukoopia.
nõuded:
- Sagedus: 2 korda päevas;
- Hoidke koopiaid viimase 90 päeva jooksul;
- Vajadusel võimalus hankida üksikuid faile kindla kuupäeva kohta;
- Varukoopia tuleb salvestada VDS-ist erinevas andmekeskuses;
- Võimalus varukoopiale ligi pääseda kõikjalt (teine server, kohalik arvuti jne).
Oluline punkt oli võime kiiresti varukoopiaid luua minimaalse lisaruumi ja süsteemiressursside tarbimisega.
Me ei räägi hetktõmmisest kogu süsteemi kiireks taastamiseks, vaid konkreetselt failidest ja andmebaasist ning muudatuste ajaloost.
Esialgsed andmed:
- VDS XEN-i virtualiseerimisel;
- OS CentOS 7;
- 1C-Bitrix: Veebikeskkond;
- Veebisait, mis põhineb "1C-Bitrix: Site Management" versioonil, standardversioon;
- Faili suurus on 50 GB ja see kasvab;
- Andmebaasi suurus on 3 GB ja see kasvab.
1C-Bitrixi sisseehitatud standardne varundamine – kohe välistatud. See sobib ainult väikestele saitidele, kuna:
- Teeb iga kord saidist täieliku koopia, seega võtab iga koopia sama palju ruumi kui failid, minu puhul on see 50 GB.
- Varundamine toimub PHP abil, mis selliste failisuuruste puhul on võimatu, see koormab serverit üle ja ei lõpe kunagi.
- Ja loomulikult ei saa täieliku koopia säilitamisel 90 päevast rääkidagi.
Lahendus, mis pakub võõrustajaSee on varuketas, mis asub VDS-iga samas andmekeskuses, aga teisel serveril. Kettale pääsete ligi FTP kaudu ja saate kasutada oma skripte või, kui ISPManager on VDS-ile installitud, selle varundusmooduli kaudu. See valik ei sobi, kuna see kasutab sama andmekeskust.
Kõigist eelnevatest lähtuvalt on minu jaoks optimaalne valik järkjärguline varundamine, kasutades minu enda stsenaariumi Yandex.Cloudis (Object Storage) või Amazon S3-s (Amazon Simple Storage Service).
Selleks on vaja:
- juurjuurdepääs VDS-ile;
- installitud dubleerimise utiliit;
- konto Yandex.Cloudis.
Järkjärguline varundamine — meetod, mille puhul arhiveeritakse ainult need andmed, mis on pärast viimast varundamist muutunud.
kahepalgelisus — varundusutiliit, mis kasutab rsync algoritme ja töötab Amazon S3-ga.
Yandex.Cloud vs Amazon S3
Minu jaoks pole Yandex.Cloudi ja Amazon S3 vahel antud juhul mingit vahet. Yandex toetab Amazon S3 API põhiosa, seega saate sellega töötada, kasutades olemasolevaid lahendusi S3-ga töötamiseks. Minu puhul on selleks duplicity utiliit.
Yandexi peamine eelis võib olla rublades maksmine, kui andmeid on palju, siis vahetuskursiga seost ei ole. Kiiruse poolest töötavad Amazoni Euroopa andmekeskused Yandexis võrreldavalt Venemaa omadega, näiteks saate kasutada Frankfurti. Varem kasutasin sarnaste ülesannete jaoks Amazon S3-e, nüüd otsustasin proovida Yandexi.
Yandex.Cloudi seadistamine
1. Peate looma Yandex.Cloudis maksekonto. Selleks peate Yandex.Cloudi sisse logima oma Yandexi konto kaudu või looma uue konto.
2. Loo "pilv".

3. Loo "Pilves" "kataloog".

4. "Kataloogi" jaoks looge "Teenusekonto".

5. Looge teenusekontole võtmed.

6. Hoidke võtmed alles, neid läheb hiljem vaja.

7. "Kataloogi" jaoks loo "Ämber", kuhu failid paigutatakse.

8. Soovitan määrata limiidi ja valida "Külmhoidla".

Ajastatud varukoopiate seadistamine serveris
See juhend eeldab elementaarseid administratiivseid oskusi.
1. Paigaldage VDS-i duplikatsiooniutiliit
yum install duplicity2. Loo MySQL-i prügimägede jaoks kaust, minu puhul on see VDS-i juurkataloogis /backup_db
3. Loo bash-skriptide jaoks kaust /backup_scripts ja tee esimene skript, mis teeb varundamise /backup_scripts/backup.sh
Skripti sisu:
#!`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. Käivita skript esimest korda ja kontrolli tulemust; failid peaksid ilmuma kausta „Ämber“.
`which bash` /backup_scripts/backup.sh
5. Lisa root-kasutajale cronile skript, mida saab käivitada kaks korda päevas või vastavalt vajadusele.
10 4,16 * * * `which bash` /backup_scripts/backup.shAndmete taastamine Yandex.Cloudist
1. Loo taastekaust /backup_restore
2. Loo taastamiseks bash-skript /backup_scripts/restore.sh
Toon kõige populaarsema näite konkreetse faili taastamisest:
#!`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. Käivita skript ja oota tulemust.
`which bash` /backup_scripts/backup.shKaustast /backup_restore/ leiad faili index.php, mis oli eelnevalt varukoopiasse lisatud.
Saate teha rohkem peenhäälestust vastavalt oma vajadustele.
Miinus kahepalgelisus
Duplicityl on üks puudus – kanali kasutamisele pole võimalik piirangut seada. Tavalise kanali puhul pole see probleem, aga DDoS-kaitsega kanali kasutamisel päevase kiirusearveldusega tahaksin, et saaksin piiranguks seada 1-2 megabitti.
Kokkuvõtteks
Yandex.Cloudi või Amazon S3-sse varundamine annab teie veebisaidist ja operatsioonisüsteemi sätetest sõltumatu koopia, millele pääseb ligi mis tahes muust serverist või kohalikust arvutist. See koopia pole kellelegi nähtav. juhtpaneelid hostingus ega ka Bitrixi administraatoripaneelil, mis pakub täiendavat turvalisust.
Halvimal juhul saate kokku panna uue serveri ja saidi mis tahes kuupäevaks juurutada. Kõige populaarsem funktsioon on aga failile juurdepääsu saamine kindla kuupäeva jaoks.
Seda meetodit saab kasutada mis tahes VDS-i või spetsiaalserverite ja saitidega mis tahes mootoritel, mitte ainult 1C-Bitrixil. Operatsioonisüsteem võib erineda ka CentOS-ist, näiteks Ubuntu või Debian.
Allikas: www.habr.com
