🥇Inkrementele VDS-rugsteun met 'n webwerf op 1C-Bitrix in Yandex.Cloud

Dit was vir my nodig om die webwerf na 2C-Bitrix: Site Management 1 keer per dag te rugsteun (lêers en mysql databasis) en 'n geskiedenis van veranderinge vir 90 dae te stoor.

Die webwerf is geleë op 'n VDS met CentOS 7 met "1C-Bitrix: Web Environment" geïnstalleer. Maak ook 'n rugsteunkopie van die OS-instellings.

vereistes:

Frekwensie - 2 keer per dag;
Hou kopieë vir die afgelope 90 dae;
Die vermoë om individuele lêers vir 'n spesifieke datum te kry, indien nodig;
Die rugsteun moet in 'n ander datasentrum as VDS gestoor word;
Die vermoë om vanaf enige plek toegang tot die rugsteun te verkry ('n ander bediener, plaaslike rekenaar, ens.).

'n Belangrike punt was die vermoë om vinnig rugsteun te skep met minimale verbruik van bykomende spasie en stelselhulpbronne.

Dit gaan nie oor 'n momentopname vir 'n vinnige herstel van die hele stelsel nie, maar oor lêers en die databasis en die geskiedenis van veranderinge.

Aanvanklike gegewens:

VDS op XEN-virtualisering;
OS CentOS 7;
1C-Bitrix: Webomgewing;
Webwerf gebaseer op "1C-Bitrix: Site Management", Standaard weergawe;
Die lêergrootte is 50 GB en sal groei;
Die databasisgrootte is 3 GB en sal groei.

Standaard rugsteun ingebou in 1C-Bitrix - onmiddellik uitgesluit. Dit is slegs geskik vir klein terreine, want:

Maak 'n volledige kopie van die webwerf onderskeidelik elke keer, elke kopie sal soveel spasie opneem as wat ek die lêers opneem, in my geval is dit 50 GB.
Rugsteun word gedoen met PHP, wat onmoontlik is met sulke volumes lêers, dit sal die bediener oorlaai en sal nooit eindig nie.
En natuurlik kan daar nie sprake wees van enige 90 dae wanneer 'n volledige kopie gestoor word nie.

Die oplossing wat die gasheer bied, is 'n rugsteunskyf wat in dieselfde datasentrum as die VDS geleë is, maar op 'n ander bediener. Jy kan met die skyf werk via FTP en jou eie skrifte gebruik, of as ISPManager op die VDS geïnstalleer is, dan deur sy rugsteunmodule. Hierdie opsie is nie geskik nie as gevolg van die gebruik van dieselfde datasentrum.

Uit al die bogenoemde is die beste keuse vir my 'n inkrementele rugsteun volgens my eie scenario in Yandex.Cloud (Object Storage) of Amazon S3 (Amazon Simple Storage Service).

Dit vereis:

worteltoegang tot VDS;
geïnstalleerde duplicity nut;
rekening in Yandex.Cloud.

inkrementele rugsteun - 'n metode waarin slegs data wat sedert die laaste rugsteun verander het, geargiveer word.

valsheid - 'n rugsteunprogram wat rsync-algoritmes gebruik en met Amazon S3 kan werk.

Yandex.Cloud vs Amazon S3

Daar is geen verskil tussen Yandex.Cloud en Amazon S3 in hierdie geval vir my nie. Yandex ondersteun die hoofgedeelte van die Amazon S3 API, sodat jy daarmee kan werk met behulp van die oplossings wat beskikbaar is om met S3 te werk. In my geval is dit die dubbele nut.

Die grootste voordeel van Yandex kan betaling in roebels wees, as daar baie data is, sal daar geen skakel na die kursus wees nie. Wat spoed betref, werk Amazon se Europese datasentrums in ooreenstemming met Russiese in Yandex, byvoorbeeld, jy kan Frankfurt gebruik. Ek het voorheen Amazon S3 vir soortgelyke take gebruik, nou het ek besluit om Yandex te probeer.

Stel Yandex.Cloud op

1. Jy moet 'n faktuurrekening in Yandex.Cloud skep. Om dit te doen, moet jy deur jou Yandex-rekening by Yandex.Cloud aanmeld of 'n nuwe een skep.

2. Skep Wolk.

3. Skep 'n "Katalogus" in die "Wolk".

4. Skep 'n "Diensrekening" vir die "Katalogus".

5. Skep sleutels vir die "Diensrekening".

6. Hou die sleutels, jy sal dit in die toekoms nodig hê.

7. Vir die "Katalogus" skep 'n "Bucket", lêers sal daarin val.

8. Ek beveel aan om 'n limiet te stel en "Koelberging" te kies.

Stel geskeduleerde rugsteun op die bediener op

Hierdie gids veronderstel basiese administratiewe vaardighede.

1. Installeer die duplicity nut op die VDS

yum install duplicity

2. Skep 'n gids vir mysql-stortings, in my geval is dit /backup_db in die VDS-wortel

3. Skep 'n vouer vir bash scripts /backup_scripts en maak die eerste script wat /backup_scripts/backup.sh sal rugsteun

Skrip inhoud:

#!`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. Begin die script vir die eerste keer en kontroleer die resultaat, lêers moet in die Emmer verskyn.

`which bash` /backup_scripts/backup.sh

5. Voeg 'n script by cron vir die wortelgebruiker om 2 keer per dag uitgevoer te word, of so gereeld as wat jy nodig het.

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

Dataherwinning vanaf Yandex.Cloud

1. Maak 'n herstellêergids /backup_restore

2. Maak bash restore script /backup_scripts/restore.sh

Ek gee die mees gevraagde voorbeeld van die herstel van 'n spesifieke lêer:

#!`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. Begin die skrif en wag vir die resultaat.

`which bash` /backup_scripts/backup.sh

In die /backup_restore/-lêergids sal jy die index.php-lêer vind wat voorheen by die rugsteun ingesluit was.

Jy kan fyner aanpassings maak om by jou behoeftes te pas.

minus dubbelsinnigheid

Duplisering het een nadeel - daar is geen manier om 'n kanaalgebruiklimiet te stel nie. Met 'n normale kanaal skep dit nie 'n probleem nie, maar met 'n DDoS-beskermde kanaal met spoed per dag fakturering wil ek graag 'n limiet van 1-2 megabits kan stel.

As gevolgtrekking

Rugsteun in Yandex.Cloud of Amazon S3 bied 'n onafhanklike kopie van die webwerf en OS-instellings wat vanaf enige ander bediener of plaaslike rekenaar verkry kan word. Terselfdertyd is hierdie kopie nie sigbaar in die gasheerbeheerpaneel of in die Bitrix-administrasiepaneel nie, wat bykomende sekuriteit bied.

In die mees ongelukkige uitkoms kan u 'n nuwe bediener bou en die webwerf vir enige datum ontplooi. Alhoewel die mees gevraagde funksionaliteit die vermoë sal wees om toegang tot die lêer vir 'n spesifieke datum te verkry.

Jy kan hierdie tegniek gebruik met enige VDS of Toegewyde bedieners en webwerwe op enige enjins, nie net 1C-Bitrix nie. Die bedryfstelsel kan ook anders as CentOS wees, soos Ubuntu of Debian.

Bron: will.com

Inkrementele VDS-rugsteun met 'n webwerf op 1C-Bitrix in Yandex.Cloud

Yandex.Cloud vs Amazon S3

Stel Yandex.Cloud op

Stel geskeduleerde rugsteun op die bediener op

Dataherwinning vanaf Yandex.Cloud

As gevolgtrekking

Voeg 'n opmerking Kanselleer antwoord