Przyrostowa kopia zapasowa VDS z witryną na 1C-Bitrix w Yandex.Cloud

Konieczne było dla mnie wykonanie kopii zapasowej witryny w 2C-Bitrix: Zarządzanie witryną 1 razy dziennie (pliki i baza danych mysql) i przechowywanie historii zmian przez 90 dni.

Witryna znajduje się na VDS z systemem CentOS 7 z zainstalowanym „1C-Bitrix: Web Environment”. Dodatkowo wykonaj kopię zapasową ustawień systemu operacyjnego.

wymagania:

• Częstotliwość - 2 razy dziennie;
• Przechowuj kopie przez ostatnie 90 dni;
• Możliwość uzyskania pojedynczych plików na konkretny termin, jeśli zajdzie taka potrzeba;
• Kopia zapasowa musi być przechowywana w centrum danych innym niż VDS;
• Możliwość dostępu do kopii zapasowej z dowolnego miejsca (inny serwer, komputer lokalny itp.).

Ważnym punktem była możliwość szybkiego tworzenia kopii zapasowych przy minimalnym zużyciu dodatkowej przestrzeni i zasobów systemowych.

Tu nie chodzi o snapshot umożliwiający szybkie przywrócenie całego systemu, ale o pliki i bazę danych oraz historię zmian.

Linia bazowa:

• VDS na wirtualizacji XEN;
• system operacyjny CentOS 7;
• 1C-Bitrix: Środowisko sieciowe;
• Witryna oparta na „1C-Bitrix: Zarządzanie witryną”, wersja standardowa;
• Rozmiar pliku wynosi 50 GB i będzie rosnąć;
• Rozmiar bazy danych wynosi 3 GB i będzie rósł.

Standardowa kopia zapasowa wbudowana w 1C-Bitrix - natychmiast wykluczona. Nadaje się tylko do małych witryn, ponieważ:

• Za każdym razem wykonuje kompletną kopię strony odpowiednio każda kopia będzie zajmowała tyle miejsca ile zajmę plików, w moim przypadku jest to 50 GB.
• Backup odbywa się przy pomocy PHP, co przy takiej ilości plików jest niemożliwe, przeciąży serwer i nigdy się nie skończy.
• I oczywiście nie można mówić o jakichkolwiek 90 dniach przechowywania pełnej kopii.

Rozwiązanie, które oferuje gospodarzTo dysk zapasowy znajdujący się w tym samym centrum danych co VDS, ale na innym serwerze. Dostęp do dysku można uzyskać przez FTP i za pomocą własnych skryptów lub, jeśli na VDS zainstalowany jest program ISPManager, za pośrednictwem jego modułu kopii zapasowych. Ta opcja nie jest odpowiednia, ponieważ korzysta z tego samego centrum danych.

Z powyższego najlepszym dla mnie wyborem jest przyrostowa kopia zapasowa według mojego własnego scenariusza w Yandex.Cloud (Object Storage) lub Amazon S3 (Amazon Simple Storage Service).

To wymaga:

• dostęp root do VDS;
• zainstalowane narzędzie do duplikacji;
• konto w Yandex.Cloud.

Przyrostowa kopia zapasowa - metoda, w której archiwizowane są tylko dane, które uległy zmianie od czasu ostatniej kopii zapasowej.

dwulicowość - narzędzie do tworzenia kopii zapasowych, które wykorzystuje algorytmy rsync i może współpracować z Amazon S3.

Yandex.Cloud kontra Amazon S3

Dla mnie nie ma w tym przypadku różnicy pomiędzy Yandex.Cloud i Amazon S3. Yandex obsługuje główną część API Amazon S3, więc możesz z nim pracować, korzystając z rozwiązań dostępnych do pracy z S3. W moim przypadku jest to narzędzie do duplikacji.

Główną zaletą Yandex może być płatność w rublach, jeśli jest dużo danych, nie będzie linku do kursu. Pod względem szybkości europejskie centra danych Amazon działają proporcjonalnie do rosyjskich w Yandex, na przykład można korzystać z Frankfurtu. Wcześniej do podobnych zadań korzystałem z Amazon S3, teraz zdecydowałem się wypróbować Yandex.

Konfigurowanie Yandex.Cloud

1. Musisz utworzyć konto rozliczeniowe w Yandex.Cloud. Aby to zrobić, musisz zalogować się do Yandex.Cloud za pośrednictwem swojego konta Yandex lub utworzyć nowe.

2. Utwórz chmurę.


3. W „Chmurze” utwórz „Katalog”.


4. Dla „Katalogu” utwórz „Konto serwisowe”.


5. Dla „Konta usługi” utwórz klucze.


6. Zachowaj klucze, będą Ci potrzebne w przyszłości.


7. Dla „Katalogu” utwórz „Wiadro”, pliki będą do niego wpadać.


8. Polecam ustawić limit i wybrać opcję „Cold Storage”.

Konfigurowanie zaplanowanych kopii zapasowych na serwerze

W tym przewodniku założono podstawowe umiejętności administracyjne.

1. Zainstaluj narzędzie do duplikacji na VDS

yum install duplicity

2. Utwórz folder dla zrzutów mysql, w moim przypadku jest to /backup_db w katalogu głównym VDS

3. Utwórz folder dla skryptów bash /backup_scripts i utwórz pierwszy skrypt, który utworzy kopię zapasową /backup_scripts/backup.sh

Treść skryptu:

#!`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. Uruchom skrypt po raz pierwszy i sprawdź wynik, pliki powinny pojawić się w Buckecie.

`which bash` /backup_scripts/backup.sh

5. Dodaj skrypt do crona, który będzie uruchamiany przez użytkownika root 2 razy dziennie lub tak często, jak potrzebujesz.

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

Odzyskiwanie danych z Yandex.Cloud

1. Utwórz folder przywracania /backup_restore

2. Utwórz skrypt przywracania basha /backup_scripts/restore.sh

Podaję najbardziej pożądany przykład odzyskiwania konkretnego pliku:

#!`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. Uruchom skrypt i poczekaj na wynik.

`which bash` /backup_scripts/backup.sh

W folderze /backup_restore/ znajdziesz plik indeks.php, który był wcześniej zawarty w kopii zapasowej.

Możesz dokonać dokładniejszych regulacji, aby dostosować je do swoich potrzeb.

minus dwulicowość

Duplikat ma jedną wadę - nie ma możliwości ustalenia limitu wykorzystania kanału. W przypadku normalnego kanału nie stanowi to problemu, ale w przypadku kanału chronionego przed DDoS z rozliczaniem za prędkość dziennie chciałbym móc ustawić limit na 1-2 megabity.

Jako podsumowanie

Tworzenie kopii zapasowej w Yandex.Cloud lub Amazon S3 zapewnia niezależną kopię ustawień witryny i systemu operacyjnego, do której można uzyskać dostęp z dowolnego innego serwera lub komputera lokalnego. Ta kopia nie jest widoczna dla nikogo. panel kontrolny hostingu, ani w panelu administracyjnym Bitrix, który zapewnia dodatkowe bezpieczeństwo.

W najbardziej niefortunnym przypadku możesz zbudować nowy serwer i wdrożyć witrynę w dowolnym terminie. Chociaż najbardziej pożądaną funkcjonalnością będzie możliwość dostępu do pliku w określonym terminie.

Możesz użyć tej techniki z dowolnymi serwerami i witrynami VDS lub dedykowanymi na dowolnych silnikach, nie tylko 1C-Bitrix. System operacyjny może być również inny niż CentOS, taki jak Ubuntu lub Debian.

Źródło: www.habr.com