🥇Copiere de rezervă incrementală a VDS cu un site pe 1C-Bitrix în Yandex.Cloud

Trebuia să fac copii de rezervă ale site-ului pe „2C-Bitrix: Site Management” (fișiere și baza de date mysql) de două ori pe zi și să stochez un istoric al modificărilor timp de 1 de zile.

Site-ul este situat pe un VDS care rulează CentOS 7 OS cu 1C-Bitrix: Web Environment instalat. În plus, faceți o copie de rezervă a setărilor sistemului de operare.

Cerinte:

Frecvență - de 2 ori pe zi;
Păstrați copii pentru ultimele 90 de zile;
Posibilitatea de a obține fișiere individuale pentru o anumită dată, dacă este necesar;
Backup-ul trebuie să fie stocat într-un alt centru de date decât VDS;
Posibilitatea de a accesa backup-ul de oriunde (alt server, computer local etc.).

Un punct important a fost capacitatea de a crea rapid copii de rezervă cu un consum minim de spațiu suplimentar și resurse de sistem.

Nu este vorba despre un instantaneu pentru restaurarea rapidă a întregului sistem, ci despre fișiere și baza de date și istoricul modificărilor.

Date inițiale:

VDS pe virtualizarea XEN;
OS CentOS 7;
1C-Bitrix: mediu web;
Website bazat pe „1C-Bitrix: Site Management”, versiunea standard;
Dimensiunea fișierului este de 50 GB și va crește;
Dimensiunea bazei de date este de 3 GB și va crește.

Am exclus imediat backup-ul standard încorporat în 1C-Bitrix. Este potrivit doar pentru site-uri mici, deoarece:

Face o copie completă a site-ului de fiecare dată, așa că fiecare copie va ocupa aceeași cantitate de spațiu pe care o ocupă fișierele, în cazul meu este de 50 GB.
Backup-ul se face folosind PHP, ceea ce este imposibil cu astfel de volume de fișiere, va supraîncărca serverul și nu se va termina niciodată.
Și, desigur, nu se poate vorbi despre vreo 90 de zile când stocați o copie completă.

Soluția care oferă gazdăAcesta este un disc de rezervă situat în același centru de date ca și VDS, dar pe un server diferit. Puteți accesa discul prin FTP și puteți utiliza propriile scripturi sau, dacă ISPManager este instalat pe VDS, prin intermediul modulului său de rezervă. Această opțiune nu este potrivită deoarece utilizează același centru de date.

Dintre toate cele de mai sus, cea mai bună alegere pentru mine este o copie de rezervă incrementală folosind propriul meu script în Yandex.Cloud (Object Storage) sau Amazon S3 (Amazon Simple Storage Service).

Este nevoie de:

acces root la VDS;
utilitarul de duplicitate instalat;
cont în Yandex.Cloud.

Backup incremental — o metodă în care sunt arhivate numai datele care s-au modificat de la ultima copie de rezervă.
duplicitate — un utilitar de rezervă care utilizează algoritmi rsync și poate funcționa cu Amazon S3.

Yandex.Cloud vs Amazon S3

În acest caz, nu există nicio diferență între Yandex.Cloud și Amazon S3 pentru mine. Yandex acceptă cea mai mare parte a API-ului Amazon S3, astfel încât să puteți lucra cu acesta folosind soluțiile existente pentru lucrul cu S3. În cazul meu, acesta este utilitatea duplicității.

Principalul avantaj al Yandex poate fi plata în ruble, dacă există o mulțime de date, nu va exista nicio legătură cu cursul de schimb. În ceea ce privește viteza, centrele de date europene ale Amazon funcționează comparabil cu centrele de date rusești din Yandex, de exemplu, puteți folosi Frankfurt. Am folosit anterior Amazon S3 pentru sarcini similare, dar acum am decis să încerc Yandex.

Configurarea Yandex.Cloud

1. Trebuie să creați un cont de plată în Yandex.Cloud. Pentru a face acest lucru, trebuie să vă conectați la Yandex.Cloud prin contul Yandex sau să creați unul nou.

2. Creați un „Cloud”.

3. În „Cloud” creați un „Catalog”.

4. Pentru „Catalog” creați un „Cont de serviciu”.

5. Creați chei pentru „Contul de serviciu”.

6. Păstrați cheile, vor fi necesare în viitor.

7. Pentru „Director” creați un „Bucket”, fișierele vor intra în el.

8. Recomand să setați o limită și să selectați „Depozitare la rece”.

Configurarea backup-urilor programate pe server

Acest ghid presupune abilități de administrare de bază.

1. Instalați utilitarul de duplicitate pe VDS

yum install duplicity

2. Creați un folder pentru depozitele mysql, în cazul meu este /backup_db în rădăcina VDS

3. Creați un folder pentru scripturile bash /backup_scripts și creați primul script care va efectua copii de rezervă /backup_scripts/backup.sh

Conținutul scriptului:

#!`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. Rulați scriptul pentru prima dată și verificați că fișierele ar trebui să apară în „Bucket”.

`which bash` /backup_scripts/backup.sh

5. Adăugați un script la cron pentru ca utilizatorul root să ruleze de 2 ori pe zi sau cu frecvența de care aveți nevoie.

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

Recuperarea datelor de pe Yandex.Cloud

1. Creați un folder de recuperare /backup_restore

2. Creați un script bash pentru recuperare /backup_scripts/restore.sh

Dau cel mai popular exemplu de restaurare a unui anumit fișier:

#!`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. Rulați scriptul și așteptați rezultatul.

`which bash` /backup_scripts/backup.sh

În folderul /backup_restore/ veți găsi fișierul index.php care a fost copiat anterior.

Puteți face ajustări mai fine pentru a se potrivi nevoilor dvs.

Minus duplicare

duplicitatea are un dezavantaj - nu este posibil să se stabilească o limită de utilizare a canalului. Cu un canal obișnuit, acest lucru nu creează o problemă, dar când folosesc un canal protejat prin DDoS cu încărcare rapidă pe zi, aș dori să pot seta o limită de 1-2 megabiți.

Drept concluzie

Copierea de rezervă pe Yandex.Cloud sau Amazon S3 oferă o copie independentă a site-ului web și a setărilor sistemului de operare, care poate fi accesată de pe orice alt server sau computer local. Această copie nu este vizibilă nimănui. panouri de control găzduire, nici în panoul de administrare Bitrix, care oferă securitate suplimentară.

În cel mai rău caz, puteți asambla un nou server și puteți implementa site-ul la orice dată. Deși cea mai populară funcționalitate va fi abilitatea de a accesa un fișier pentru o anumită dată.

Puteți utiliza această tehnică cu orice VDS sau servere și site-uri dedicate pe orice motoare, nu doar 1C-Bitrix. Sistemul de operare poate fi, de asemenea, altul decât CentOS, cum ar fi Ubuntu sau Debian.

Sursa: www.habr.com