🥇 Täiendav VDS-i varundamine veebisaidiga 1C-Bitrixis Yandex.Cloudis

Mul oli vaja teha saidi varukoopiaid 2 korda päevas rakenduses "1C-Bitrix: Site Management" (failid ja mysql-i andmebaas) ja salvestada muudatuste ajalugu 90 päeva.

Sait asub VDS-is, kus töötab CentOS 7 OS ja on installitud 1C-Bitrix: Web Environment. Lisaks tehke oma OS-i sätetest varukoopia.

nõuded:

Sagedus - 2 korda päevas;
Säilitage koopiad viimased 90 päeva;
Võimalus hankida vajadusel üksikuid faile kindla kuupäeva jaoks;
Varukoopiat tuleb hoida muus andmekeskuses kui VDS;
Võimalus pääseda juurde varukoopiale kõikjalt (teisest serverist, kohalikust arvutist jne).

Oluline punkt oli võimalus kiiresti luua varukoopiaid minimaalse lisaruumi ja süsteemiressursside tarbimisega.

See ei puuduta hetktõmmist kogu süsteemi kiireks taastamiseks, vaid failide ja andmebaasi ning muudatuste ajaloo kohta.

Esialgsed andmed:

VDS XEN virtualiseerimisel;
OS CentOS 7;
1C-Bitrix: veebikeskkond;
Veebisait põhineb “1C-Bitrix: Site Management”, standardversioon;
Faili suurus on 50 GB ja see kasvab;
Andmebaasi suurus on 3 GB ja see kasvab.

Välistasin kohe 1C-Bitrixisse sisseehitatud standardse varukoopia. See sobib ainult väikestele saitidele, kuna:

See teeb saidist iga kord täiskoopia, nii et iga koopia võtab sama palju ruumi kui failid, minu puhul on see 50 GB.
Varundamine toimub PHP-ga, mis sellise failimahuga on võimatu, see koormab serverit üle ega lõpe kunagi.
Ja loomulikult ei saa täieliku koopia salvestamisel rääkida 90 päevast.

Lahendus, mida hoster pakub, on varuketas, mis asub VDS-iga samas andmekeskuses, kuid teises serveris. Kettaga saate töötada FTP kaudu ja kasutada oma skripte või kui ISPManager on VDS-i installitud, siis selle varundusmooduli kaudu. See valik ei sobi sama andmekeskuse kasutamise tõttu.

Kõigest ülaltoodust on minu jaoks parim valik varundamine, kasutades minu enda skripti Yandex.Cloudis (Object Storage) või Amazon S3-s (Amazon Simple Storage Service).

Selleks on vaja:

juurjuurdepääs VDS-ile;
installitud kahepalgelisuse utiliit;
konto Yandex.Cloudis.

Täiendav varundamine — meetod, mille puhul arhiveeritakse ainult andmed, mis on muutunud pärast viimast varukoopiat.

kahepalgelisus — varuutiliit, mis kasutab rsynci algoritme ja suudab töötada Amazon S3-ga.

Yandex.Cloud vs Amazon S3

Sel juhul pole Yandex.Cloudil ja Amazon S3-l minu jaoks vahet. Yandex toetab suurt osa Amazon S3 API-st, nii et saate sellega töötada, kasutades S3-ga töötamiseks olemasolevaid lahendusi. Minu puhul on see kahepalgelisuse utiliit.

Yandexi peamine eelis võib olla rublades maksmine; kui andmeid on palju, pole vahetuskursiga ühendust. Kiiruse poolest töötavad Amazoni Euroopa andmekeskused võrreldavalt Venemaa andmekeskustega Yandexis, kasutada saab näiteks Frankfurti. Varem kasutasin sarnaste ülesannete jaoks Amazon S3, nüüd otsustasin proovida Yandexi.

Yandex.Cloudi seadistamine

1. Peate looma Yandex.Cloudis maksekonto. Selleks peate oma Yandexi konto kaudu Yandex.Cloudi sisse logima või looma uue.

2. Looge "pilv".

3. Looge "Pilves" "Kataloog".

4. "Kataloogi" jaoks looge "Teenuse konto".

5. Looge "Teenusekonto" võtmed.

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

7. Loo "Kataloogi" jaoks "Ämber", failid lähevad sinna.

8. Soovitan seada limiit ja valida “Cold Storage”.

Ajastatud varukoopiate seadistamine serveris

See juhend eeldab põhilisi haldusoskusi.

1. Installige VDS-i duplicity-utiliit

yum install duplicity

2. Looge kaust mysql dumpide jaoks, minu puhul on see VDS-i juures /backup_db

3. Looge bash-skriptide kaust /backup_scripts ja tehke esimene skript, mis teeb varukoopiaid /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;

fi

4. Käivitage skript esimest korda ja kontrollige tulemust; failid peaksid ilmuma ämbrisse.

`which bash` /backup_scripts/backup.sh

5. Lisage cronile skript, mida juurkasutaja töötab 2 korda päevas või vajaliku sagedusega.

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

Andmete taastamine Yandex.Cloudist

1. Looge taastekaust /backup_restore

2. Looge taastamiseks bash-skript /backup_scripts/restore.sh

Toon konkreetse faili taastamise kõige populaarsema näite:

#!`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. Käivitage skript ja oodake tulemust.

`which bash` /backup_scripts/backup.sh

Kaustast /backup_restore/ leiate faili index.php, millest oli varem varundatud.

Saate teha täpsemaid muudatusi vastavalt oma vajadustele.

Miinus dubleerimine

kahepalgelisusel on üks puudus – kanali kasutuspiirangut pole võimalik seada. Tavakanaliga see probleemi ei tekita, aga DDoS-kaitsega kiirlaadimisega kanalit päevas kasutades tahaks 1-2 megabitti piiri panna.

Kokkuvõtteks

Varundamine Yandex.Cloudis või Amazon S3-s pakub saidi ja OS-i sätete sõltumatut koopiat, millele pääseb juurde mis tahes muust serverist või kohalikust arvutist. Pealegi pole see koopia nähtav ei hostimise juhtpaneelil ega Bitrixi administraatoripaneelil, mis pakub täiendavat turvalisust.

Halvimal juhul saate uue serveri kokku panna ja saidi igal ajal juurutada. Kuigi kõige populaarsem funktsioon on võimalus pääseda juurde konkreetse kuupäeva failile.

Saate seda tehnikat kasutada mis tahes VDS-i või spetsiaalsete serverite ja saitidega mis tahes mootoris, mitte ainult 1C-Bitrixis. OS võib olla ka muu kui CentOS, näiteks Ubuntu või Debian.

Allikas: www.habr.com

Täiendav VDS-i varundamine saidiga 1C-Bitrixis Yandex.Cloudis

Yandex.Cloud vs Amazon S3

Yandex.Cloudi seadistamine

Ajastatud varukoopiate seadistamine serveris

Andmete taastamine Yandex.Cloudist

Kokkuvõtteks

Lisa kommentaar Tühista vastus