Stigvaxandi VDS öryggisafrit með síðu á 1C-Bitrix í Yandex.Cloud

Ég þurfti að taka afrit af síðunni á „2C-Bitrix: Site Management“ (skrár og mysql gagnagrunnur) tvisvar á dag og geyma breytingasögu í 1 daga.

Síðan er staðsett á VDS sem keyrir CentOS 7 OS með 1C-Bitrix: Web Environment uppsett. Að auki skaltu taka öryggisafrit af stýrikerfisstillingunum þínum.

Kröfur:

• Tíðni - 2 sinnum á dag;
• Geymdu afrit síðustu 90 daga;
• Hæfni til að fá einstakar skrár fyrir ákveðna dagsetningu, ef þörf krefur;
• Afritið verður að vera geymt í öðru gagnaveri en VDS;
• Möguleikinn á að fá aðgang að öryggisafritinu hvar sem er (annar þjónn, staðbundin tölva osfrv.).

Mikilvægur punktur var hæfileikinn til að búa til afrit á fljótlegan hátt með lágmarksnotkun á viðbótarplássi og kerfisauðlindum.

Þetta snýst ekki um skyndimynd til að endurheimta allt kerfið hratt, heldur um skrár og gagnagrunn og breytingasögu.

Upphafleg gögn:

• VDS á XEN sýndarvæðingu;
• OS CentOS 7;
• 1C-Bitrix: Vefumhverfi;
• Vefsíða byggð á „1C-Bitrix: Site Management“, staðlaðri útgáfu;
• Skráarstærð er 50 GB og mun stækka;
• Stærð gagnagrunnsins er 3 GB og mun stækka.

Ég útilokaði strax staðlaða öryggisafritið sem var innbyggt í 1C-Bitrix. Það er aðeins hentugur fyrir litlar síður, vegna þess að:

• Það gerir fullt afrit af síðunni í hvert skipti, þannig að hvert eintak mun taka sama magn af plássi og skrárnar taka upp, í mínu tilfelli er það 50 GB.
• Afritun er gerð með PHP, sem er ómögulegt með slíkt magn af skrám, það mun ofhlaða þjóninum og mun aldrei klára.
• Og auðvitað er ekki hægt að tala um neina 90 daga þegar heilt eintak er geymt.

Lausnin sem hýsingaraðilinn býður upp á er varadiskur sem staðsettur er í sama gagnaveri og VDS, en á öðrum netþjóni. Þú getur unnið með diskinn í gegnum FTP og notað eigin forskriftir, eða ef ISPManager er uppsett á VDS, þá í gegnum öryggisafritseininguna. Þessi valkostur er ekki hentugur vegna notkunar á sömu gagnaverinu.

Af öllu ofangreindu er besti kosturinn fyrir mig stigvaxandi öryggisafrit með því að nota mitt eigið handrit í Yandex.Cloud (Object Storage) eða Amazon S3 (Amazon Simple Storage Service).

Þetta krefst:

• rót aðgangur að VDS;
• uppsett tvöfalt gagnsemi;
• reikning í Yandex.Cloud.

Stigvaxandi öryggisafrit — aðferð þar sem aðeins gögn sem hafa breyst frá síðasta öryggisafriti eru geymd í geymslu.

tvíverknað — öryggisafritunarforrit sem notar rsync reiknirit og getur unnið með Amazon S3.

Yandex.Cloud vs Amazon S3

Í þessu tilfelli er enginn munur á Yandex.Cloud og Amazon S3 fyrir mig. Yandex styður megnið af Amazon S3 API, svo þú getur unnið með það með því að nota þær lausnir sem til eru til að vinna með S3. Í mínu tilviki er þetta tvívirkni gagnsemi.

Helsti kosturinn við Yandex getur verið greiðsla í rúblum; ef það er mikið af gögnum verður engin tenging við gengi krónunnar. Hvað varðar hraða virka evrópskar gagnaver Amazon sambærilegt við rússneskar gagnaver í Yandex; til dæmis geturðu notað Frankfurt. Ég notaði áður Amazon S3 fyrir svipuð verkefni, nú ákvað ég að prófa Yandex.

Setja upp Yandex.Cloud

1. Þú þarft að búa til greiðslureikning í Yandex.Cloud. Til að gera þetta þarftu að skrá þig inn á Yandex.Cloud í gegnum Yandex reikninginn þinn eða búa til nýjan.

2. Búðu til "ský".


3. Búðu til "Vörulisti" í "skýinu".


4. Búðu til „Þjónustureikning“ fyrir „Vörulisti“.


5. Búðu til lykla fyrir "Þjónustureikninginn".


6. Vistaðu lyklana, þá verður þörf á þeim í framtíðinni.


7. Búðu til „Fötu“ fyrir „Möppuna“, skrár fara inn í hana.


8. Ég mæli með því að setja takmörk og velja „Kæligeymslu“.

Að setja upp áætlaða öryggisafrit á þjóninum

Þessi handbók gerir ráð fyrir grunnfærni í stjórnsýslu.

1. Settu upp tvíhliða tólið á VDS

yum install duplicity

2. Búðu til möppu fyrir mysql dumps, í mínu tilfelli er það /backup_db í VDS rótinni

3. Búðu til möppu fyrir bash forskriftir /backup_scripts og búðu til fyrsta handritið sem mun framkvæma afrit /backup_scripts/backup.sh

Innihald handrits:

#!`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. Keyrðu handritið í fyrsta skipti og athugaðu niðurstöðuna; skrár ættu að birtast í „Bucket“.

`which bash` /backup_scripts/backup.sh

5. Bættu skriftu við cron svo rótnotandinn geti keyrt 2 sinnum á dag, eða með þeirri tíðni sem þú þarft.

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

Endurheimt gögn frá Yandex.Cloud

1. Búðu til endurheimtarmöppu /backup_restore

2. Búðu til bash forskrift fyrir endurheimt /backup_scripts/restore.sh

Ég gef vinsælasta dæmið um að endurheimta tiltekna skrá:

#!`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. Keyrðu handritið og bíddu eftir niðurstöðunni.

`which bash` /backup_scripts/backup.sh

Í /backup_restore/ möppunni finnurðu index.php skrána sem var afrituð áður.

Þú getur gert fínni lagfæringar til að henta þínum þörfum.

Mínus tvíverknað

tvívirkni hefur einn galla - það er ekki hægt að setja rás notkunartakmörk. Með venjulegri rás skapar þetta ekki vandamál, en þegar þú notar DDoS-varða rás með hraðahleðslu á dag, þá myndi ég vilja geta sett hámarkið á 1-2 megabita.

Sem niðurstaða

Öryggisafritun í Yandex.Cloud eða Amazon S3 veitir sjálfstætt afrit af síðunni og stýrikerfisstillingum sem hægt er að nálgast frá hvaða öðrum netþjóni eða staðbundinni tölvu. Þar að auki er þetta eintak ekki sýnilegt hvorki á stjórnborði hýsingar eða á Bitrix stjórnborði, sem veitir aukið öryggi.

Í versta falli geturðu sett saman nýjan netþjón og sett síðuna í notkun hvenær sem er. Þó að vinsælasta virknin sé hæfileikinn til að fá aðgang að skrá fyrir ákveðna dagsetningu.

Þú getur notað þessa tækni með hvaða VDS eða sérstökum netþjónum og síðum sem er á hvaða vél sem er, ekki bara 1C-Bitrix. Stýrikerfið gæti líka verið annað en CentOS, eins og Ubuntu eða Debian.

Heimild: www.habr.com