Inkrementalna varnostna kopija VDS s spletno stranjo na 1C-Bitrix v Yandex.Cloud

Moral sem narediti varnostno kopijo spletnega mesta v 2C-Bitrix: Upravljanje spletnega mesta 1-krat na dan (datoteke in baza podatkov mysql) in shraniti zgodovino sprememb za 90 dni.

Spletno mesto se nahaja na VDS, ki izvaja CentOS 7 z nameščenim "1C-Bitrix: spletno okolje". Poleg tega naredite varnostno kopijo nastavitev OS.

Zahteve:

• Pogostost - 2-krat na dan;
• Hranite kopije za zadnjih 90 dni;
• Možnost pridobivanja posameznih datotek za določen datum, če je potrebno;
• Varnostna kopija mora biti shranjena v podatkovnem centru, ki ni VDS;
• Možnost dostopa do varnostne kopije od koder koli (drug strežnik, lokalni računalnik itd.).

Pomembna točka je bila možnost hitrega ustvarjanja varnostnih kopij z minimalno porabo dodatnega prostora in sistemskih virov.

Ne gre za posnetek za hitro obnovitev celotnega sistema, temveč za datoteke in bazo ter zgodovino sprememb.

Vir podatkov:

• VDS o virtualizaciji XEN;
• OS CentOS 7;
• 1C-Bitrix: spletno okolje;
• Spletno mesto, ki temelji na "1C-Bitrix: Upravljanje spletnega mesta", standardna različica;
• Velikost datoteke je 50 GB in bo naraščala;
• Velikost baze podatkov je 3 GB in se bo še povečevala.

Standardna varnostna kopija, vgrajena v 1C-Bitrix - takoj izključena. Primeren je le za majhna mesta, ker:

• Vsakič naredi popolno kopijo spletnega mesta, vsaka kopija bo zavzela toliko prostora, kot zasedem datoteke, v mojem primeru je to 50 GB.
• Varnostno kopiranje se izvaja s pomočjo PHP-ja, kar je pri takšni količini datotek nemogoče, preobremeni strežnik in se nikoli ne konča.
• In seveda ne more biti govora o nobenih 90 dneh pri shranjevanju celotne kopije.

Rešitev, ki jo ponuja gostitelj, je rezervni disk, ki se nahaja v istem podatkovnem centru kot VDS, vendar na drugem strežniku. Z diskom lahko delate prek FTP in uporabljate lastne skripte, ali če je ISPManager nameščen na VDS, potem prek njegovega rezervnega modula. Ta možnost ni primerna zaradi uporabe istega podatkovnega centra.

Od vsega naštetega je zame najboljša izbira inkrementalna varnostna kopija po lastnem scenariju v Yandex.Cloud (Object Storage) ali Amazon S3 (Amazon Simple Storage Service).

To zahteva:

• korenski dostop do VDS;
• nameščen pripomoček za podvajanje;
• račun v Yandex.Cloud.

inkrementalno varnostno kopiranje - način, pri katerem se arhivirajo samo podatki, ki so bili spremenjeni od zadnje varnostne kopije.

dvojnost - pripomoček za varnostno kopiranje, ki uporablja algoritme rsync in lahko deluje z Amazon S3.

Yandex.Cloud proti Amazon S3

Zame v tem primeru ni razlike med Yandex.Cloudom in Amazonom S3. Yandex podpira glavni del API-ja Amazon S3, tako da lahko z njim delate z rešitvami, ki so na voljo za delo s S3. V mojem primeru je to pripomoček za dvojnost.

Glavna prednost Yandexa je lahko plačilo v rubljih, če je veliko podatkov, potem ne bo povezave do tečaja. Kar zadeva hitrost, Amazonovi evropski podatkovni centri delujejo sorazmerno z ruskimi v Yandexu, lahko na primer uporabite Frankfurt. Prej sem za podobna opravila uporabljal Amazon S3, zdaj sem se odločil poskusiti Yandex.

Nastavitev Yandex.Cloud

1. V Yandex.Cloud morate ustvariti račun za obračunavanje. Če želite to narediti, se morate prijaviti v Yandex.Cloud prek svojega računa Yandex ali ustvariti novega.

2. Ustvari oblak.


3. V "Oblaku" ustvarite "Katalog".


4. Za "Katalog" ustvarite "Storitveni račun".


5. Za "Storitveni račun" ustvarite ključe.


6. Shranite ključe, potrebovali jih boste v prihodnosti.


7. Za "Katalog" ustvarite "Vedro", datoteke bodo padle vanj.


8. Priporočam, da nastavite omejitev in izberete "Cold Storage".

Nastavitev načrtovanih varnostnih kopij na strežniku

Ta vodnik predvideva osnovne administrativne veščine.

1. Namestite pripomoček dvojnosti na VDS

yum install duplicity

2. Ustvarite mapo za izpise mysql, v mojem primeru je to /backup_db v korenu VDS

3. Ustvarite mapo za bash skripte /backup_scripts in naredite prvi skript, ki bo varnostno kopiral /backup_scripts/backup.sh

Vsebina scenarija:

#!`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. Prvič zaženite skript in preverite rezultat, datoteke bi se morale pojaviti v vedru.

`which bash` /backup_scripts/backup.sh

5. Dodajte skript v cron za korenskega uporabnika, ki se bo izvajal 2-krat na dan ali tako pogosto, kot želite.

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

Obnovitev podatkov iz Yandex.Cloud

1. Ustvarite obnovitveno mapo /backup_restore

2. Naredi bash obnovitveni skript /backup_scripts/restore.sh

Dajem najbolj zahtevan primer obnovitve določene datoteke:

#!`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. Zaženite skript in počakajte na rezultat.

`which bash` /backup_scripts/backup.sh

V mapi /backup_restore/ boste našli datoteko index.php, ki je bila predhodno vključena v varnostno kopijo.

Naredite lahko natančnejše prilagoditve, da ustrezajo vašim potrebam.

minus dvojnost

Dvoličnost ima eno pomanjkljivost - omejitve uporabe kanala ni mogoče nastaviti. Pri običajnem kanalu to ne povzroča težav, pri DDoS zaščitenem kanalu z obračunavanjem hitrosti na dan pa bi rad imel možnost nastaviti omejitev 1-2 megabita.

Kot zaključek

Varnostno kopiranje v Yandex.Cloud ali Amazon S3 zagotavlja neodvisno kopijo nastavitev spletnega mesta in OS, do katere lahko dostopate s katerega koli drugega strežnika ali lokalnega računalnika. Hkrati ta kopija ni vidna niti v nadzorni plošči gostovanja niti v skrbniški plošči Bitrixa, kar zagotavlja dodatno varnost.

V najbolj neugodnem primeru lahko zgradite nov strežnik in uvedete spletno mesto za kateri koli datum. Čeprav bo najbolj zahtevana funkcionalnost možnost dostopa do datoteke za določen datum.

To tehniko lahko uporabite s katerim koli VDS ali namenskim strežnikom in spletnim mestom na katerem koli motorju, ne samo 1C-Bitrix. OS je lahko tudi drugačen od CentOS, na primer Ubuntu ali Debian.

Vir: www.habr.com