Növekményes VDS biztonsági mentés a Yandex.Cloud 1C-Bitrix webhelyén

Naponta kétszer biztonsági másolatot kellett készítenem a webhelyről az „2C-Bitrix: Site Management” webhelyen (fájlok és mysql adatbázis), és 1 napig tárolnom kellett a változások előzményeit.

A webhely CentOS 7 rendszert futtató VDS-en található, amelyre telepítve van az „1C-Bitrix: Web Environment”. Ezenkívül készítsen biztonsági másolatot az operációs rendszer beállításairól.

követelmények:

• Gyakoriság - napi 2 alkalommal;
• A másolatok megőrzése az elmúlt 90 napban;
• Lehetőség az egyes fájlok egy adott időpontra történő beszerzésére, ha szükséges;
• A biztonsági másolatot a VDS-től eltérő adatközpontban kell tárolni;
• Lehetőség a biztonsági másolat elérésére bárhonnan (egy másik szerverről, helyi számítógépről stb.).

Fontos szempont volt a gyors biztonsági mentések létrehozásának lehetősége a további hely és rendszererőforrások minimális felhasználásával.

Itt nem a teljes rendszer gyors visszaállításához szükséges pillanatképről van szó, hanem a fájlokról, az adatbázisról és a változások történetéről.

Forrás adatok:

• VDS XEN virtualizáción;
• OS CentOS 7;
• 1C-Bitrix: webes környezet;
• Az "1C-Bitrix: Site Management" szabványon alapuló webhely, Standard verzió;
• A fájl mérete 50 GB, és növekedni fog;
• Az adatbázis mérete 3 GB, és növekedni fog.

Azonnal kizártam az 1C-Bitrixbe épített szabványos biztonsági mentést. Csak kis helyekre alkalmas, mert:

• Minden alkalommal teljes másolatot készít az oldalról, minden másolat annyi helyet foglal el, amennyit én a fájlokat, esetemben 50 GB.
• A biztonsági mentés PHP-vel történik, ami ilyen mennyiségű fájl esetén lehetetlen, túlterheli a szervert, és soha nem fejeződik be.
• És természetesen szó sem lehet 90 napról egy teljes példány tárolása során.

A tárhelyszolgáltató által kínált megoldás egy biztonsági mentési lemez, amely ugyanabban az adatközpontban található, mint a VDS, de egy másik szerveren. A lemezzel FTP-n keresztül dolgozhat, és saját szkriptjeit használhatja, vagy ha az ISPManager telepítve van a VDS-re, akkor annak biztonsági mentési modulján keresztül. Ez a lehetőség nem megfelelő, mivel ugyanazt az adatközpontot használja.

A fentiek közül a legjobb választás számomra egy növekményes biztonsági mentés a saját forgatókönyvem szerint a Yandex.Cloudban (Object Storage) vagy az Amazon S3-ban (Amazon Simple Storage Service).

Ehhez szükség van:

• root hozzáférés a VDS-hez;
• telepített duplicity segédprogram;
• fiók a Yandex.Cloudban.

növekményes biztonsági mentés — olyan módszer, amelyben csak az utolsó biztonsági mentés óta megváltozott adatok archiválódnak.

kétszínűség - egy biztonsági mentési segédprogram, amely rsync algoritmusokat használ, és képes együttműködni az Amazon S3-mal.

Yandex.Cloud vs Amazon S3

Ebben az esetben számomra nincs különbség a Yandex.Cloud és az Amazon S3 között. A Yandex támogatja az Amazon S3 API nagy részét, így az S3-mal való együttműködéshez meglévő megoldásokkal dolgozhat vele. Az én esetemben ez a duplicity segédprogram.

A Yandex fő előnye a rubelben történő fizetés lehet, ha sok adat van, akkor nem lesz link a kurzushoz. Sebesség szempontjából az Amazon európai adatközpontjai a Yandexben lévő oroszokkal arányosan működnek, például Frankfurtot használhatja. Korábban az Amazon S3-at használtam hasonló feladatokra, most úgy döntöttem, hogy kipróbálom a Yandexet.

A Yandex.Cloud beállítása

1. Létre kell hoznia egy fizetési fiókot a Yandex.Cloudban. Ehhez be kell jelentkeznie a Yandex.Cloudba a Yandex-fiókján keresztül, vagy létre kell hoznia egy újat.

2. Felhő létrehozása.


3. A „Felhőben” hozzon létre egy „Katalógust”.


4. A „Katalógus” számára hozzon létre egy „Szolgáltatási fiókot”.


5. Hozzon létre kulcsokat a „Szolgáltatási fiókhoz”.


6. Mentsd meg a kulcsokat, a jövőben szükség lesz rájuk.


7. A „Könyvtár” számára hozzon létre egy „Vödört”, a fájlok abba kerülnek.


8. Azt javaslom, hogy állítson be egy limitet, és válassza a „Hűtőtárolás” lehetőséget.

Ütemezett biztonsági mentések beállítása a szerveren

Ez az útmutató alapvető adminisztrációs ismereteket feltételez.

1. Telepítse a duplicity segédprogramot a VDS-re

yum install duplicity

2. Hozzon létre egy mappát a mysql dumpokhoz, az én esetemben ez a /backup_db a VDS gyökérben

3. Hozzon létre egy mappát a bash szkriptek /backup_scripts számára, és készítse el az első szkriptet, amely biztonsági mentést hajt végre /backup_scripts/backup.sh

Szkript tartalma:

#!`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. Futtassa először a szkriptet, és ellenőrizze az eredményt; a fájlok megjelennek a „Vödörben”.

`which bash` /backup_scripts/backup.sh

5. Adjon hozzá egy parancsfájlt a cron-hoz a root felhasználó számára, amelyet naponta kétszer, vagy olyan gyakran kell végrehajtani, ahányszor csak szüksége van rá.

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

Adatok helyreállítása a Yandex.Cloudból

1. Hozzon létre egy visszaállítási mappát /backup_restore

2. Készítsen bash szkriptet a helyreállításhoz /backup_scripts/restore.sh

A legnépszerűbb példát adom egy adott fájl visszaállítására:

#!`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. Futtassa a szkriptet, és várja meg az eredményt.

`which bash` /backup_scripts/backup.sh

A /backup_restore/ mappában találjuk az index.php fájlt, amely korábban a biztonsági mentésben szerepelt.

Az igényeinek megfelelően finomabb beállításokat végezhet.

Mínusz duplikáció

a kettősségnek van egy hátránya – nem lehet csatornahasználati korlátot beállítani. Normál csatornánál ez nem okoz gondot, de napi gyorstöltéses DDoS-védett csatorna használatakor 1-2 megabites határt szeretnék beállítani.

Következtetésként

A Yandex.Cloudban vagy az Amazon S3-ban végzett biztonsági mentés a webhely és az operációs rendszer beállításainak független másolatát biztosítja, amely bármely más szerverről vagy helyi számítógépről elérhető. Ugyanakkor ez a másolat sem a tárhely vezérlőpultján, sem a Bitrix adminisztrációs paneljén nem látható, ami további biztonságot nyújt.

A legszerencsétlenebb esetben új kiszolgálót építhet, és bármely időpontra telepítheti a webhelyet. Bár a legkeresettebb funkció a fájl egy adott időpontra való elérése lesz.

Ezt a technikát nem csak az 1C-Bitrixen, hanem bármely VDS vagy dedikált szerveren és webhelyen használhatja. Az operációs rendszer más is lehet, mint a CentOS, például az Ubuntu vagy a Debian.

Forrás: will.com