VDS babeskopia gehigarria Yandex.Cloud-en 1C-Bitrix-en gune batekin

Gunearen babeskopiak egin behar nituen "2C-Bitrix: Site Management"-en (fitxategiak eta mysql datu-basea) egunean bitan eta 1 egunez aldaketen historia gorde.

Gunea CentOS 7 OS exekutatzen duen VDS batean dago 1C-Bitrix: Web ingurunea instalatuta. Gainera, egin zure sistema eragilearen ezarpenen babeskopia.

baldintzak:

• Maiztasuna - egunean 2 aldiz;
• Gorde kopiak azken 90 egunetan;
• Data zehatz baterako fitxategi indibidualak lortzeko gaitasuna, beharrezkoa bada;
• Babeskopia VDS ez den datu-zentro batean gorde behar da;
• Babeskopia edonondik sartzeko aukera (beste zerbitzari bat, tokiko ordenagailua, etab.).

Puntu garrantzitsu bat segurtasun kopiak azkar sortzeko gaitasuna izan zen, espazio gehigarrien eta sistemaren baliabideen gutxieneko kontsumoarekin.

Hau ez da sistema osoa azkar leheneratzeko argazki bati buruz, fitxategiei eta datu-baseari eta aldaketen historiari buruzkoa baizik.

Hasierako datuak:

• XEN birtualizazioari buruzko VDS;
• OS CentOS 7;
• 1C-Bitrix: Web ingurunea;
• "1C-Bitrix: Site Management"-n oinarritutako webgunea, bertsio estandarra;
• Fitxategiaren tamaina 50 GB da eta hazi egingo da;
• Datu-basearen tamaina 3 GB da eta hazi egingo da.

Berehala baztertu nuen 1C-Bitrix-en eraikitako babeskopia estandarra. Gune txikietarako bakarrik da egokia, zeren eta:

• Gunearen kopia osoa egiten du bakoitzean, beraz, kopia bakoitzak fitxategiek hartzen duten leku bera hartuko du, nire kasuan 50 GB da.
• Babeskopia PHP erabiliz egiten da, eta hori ezinezkoa da horrelako fitxategi-bolumenekin, zerbitzaria gainkargatuko du eta ez da inoiz amaituko.
• Eta, noski, ezin da 90 egunez hitz egin kopia osoa gordetzean.

Ostalariak eskaintzen duen irtenbidea VDSren datu-zentro berean kokatutako babeskopia-disko bat da, baina zerbitzari ezberdin batean. Diskoarekin FTP bidez lan egin dezakezu eta zure script-ak erabil ditzakezu, edo ISPManager VDSan instalatuta badago, ondoren bere babeskopia moduluaren bidez. Aukera hau ez da egokia datu-zentro bera erabiltzeagatik.

Aurreko guztiaren artean, niretzat aukerarik onena segurtasun-kopia inkrementala da nire script propioa erabiliz Yandex.Cloud (Object Storage) edo Amazon S3 (Amazon Simple Storage Service).

Horrek eskatzen du:

• VDSrako root sarbidea;
• instalatutako bikoiztasun-erabilgarritasuna;
• kontua Yandex.Cloud-en.

Babeskopia gehigarria — azken babeskopia egin zenetik aldatu diren datuak soilik artxibatzen dituen metodoa.

bikoiztasun — rsync algoritmoak erabiltzen dituen eta Amazon S3-rekin lan egin dezakeen babeskopia-erabilgarritasuna.

Yandex.Cloud vs Amazon S3

Kasu honetan, ez dago Yandex.Cloud eta Amazon S3-ren arteko alderik niretzat. Yandex-ek Amazon S3 APIaren zatirik handiena onartzen du, beraz, S3rekin lan egiteko dauden irtenbideak erabiliz lan egin dezakezu. Nire kasuan, bikoiztasunaren erabilgarritasuna da.

Yandex-en abantaila nagusia errublotan ordaintzea izan daiteke; datu asko badago, ez da truke-tasarekin loturarik egongo. Abiadurari dagokionez, Amazon-en Europako datu-zentroek Yandex-eko Errusiako datu-zentroen parean funtzionatzen dute; adibidez, Frankfurt erabil dezakezu. Lehen Amazon S3 erabiltzen nuen antzeko zereginetarako, orain Yandex probatzea erabaki nuen.

Yandex.Cloud konfiguratzen

1. Ordainketa-kontu bat sortu behar duzu Yandex.Cloud-en. Horretarako, Yandex.Cloud-en saioa hasi behar duzu Yandex kontuaren bidez edo berri bat sortu.

2. Sortu "Hodeia".


3. "Hodeian" sortu "Katalogoa".


4. “Katalogorako” sortu “Zerbitzu kontua”.


5. Sortu "Zerbitzu konturako" gakoak.


6. Gorde giltzak, etorkizunean beharrezkoak izango dira.


7. "Direktorioa" sortu "Bucket", fitxategiak bertan sartuko dira.


8. Muga bat ezartzea eta "Biltegiratzea" hautatzea gomendatzen dut.

Zerbitzarian programatutako babeskopiak konfiguratzea

Gida honek oinarrizko administrazio gaitasunak hartzen ditu bere gain.

1. Instalatu duplicity utility VDS-n

yum install duplicity

2. Sortu karpeta bat mysql zabortegietarako, nire kasuan /backup_db da VDS erroan

3. Sortu bash scriptetarako karpeta bat /backup_scripts eta egin babeskopiak egingo dituen lehen scripta /backup_scripts/backup.sh

Gidoiaren edukia:

#!`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. Exekutatu script-a lehen aldiz eta egiaztatu emaitza; fitxategiak "Bucket"-en agertu behar dira.

`which bash` /backup_scripts/backup.sh

5. Gehitu script bat cron-era erroko erabiltzaileak egunean 2 aldiz exekutatu dezan, edo behar duzun maiztasunarekin.

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

Yandex.Cloud-etik datuak berreskuratzen

1. Egin berreskuratzeko karpeta bat /backup_restore

2. Egin bash script bat /backup_scripts/restore.sh berreskuratzeko

Fitxategi zehatz bat leheneratzeko adibiderik ezagunena ematen dut:

#!`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. Exekutatu scripta eta itxaron emaitzaren arte.

`which bash` /backup_scripts/backup.sh

/backup_restore/ karpetan aurrez babeskopia egin zen index.php fitxategia aurkituko duzu.

Doikuntza finagoak egin ditzakezu zure beharretara egokitzeko.

Minus bikoizketa

bikoiztasunak eragozpen bat du: ezin da kanalaren erabilera-muga ezarri. Ohiko kanal batekin horrek ez du arazorik sortzen, baina DDoS babestutako kanal bat egunean abiadura kargatzen duen kanal bat erabiltzean, 1-2 megabit-eko muga ezarri ahal izatea gustatuko litzaidake.

Ondorio gisa

Yandex.Cloud edo Amazon S3-en babeskopiak gunearen eta OS ezarpenen kopia independentea eskaintzen du, beste edozein zerbitzaritik edo tokiko ordenagailutik atzitu daitekeen. Gainera, kopia hau ez dago ikusgai ez ostalaritzako kontrol-panelean ez Bitrix-en administrazio-panelean, eta horrek segurtasun gehigarria eskaintzen du.

Kasurik txarrenean, zerbitzari berri bat muntatu eta gunea edozein datatan zabaldu dezakezu. Funtzionalitate ezagunena data zehatz baterako fitxategi batera sartzeko aukera izango den arren.

Teknika hau edozein VDS edo Dedikatu zerbitzari eta guneekin erabil dezakezu edozein motorretan, ez 1C-Bitrix bakarrik. OSa CentOS ez den beste izan daiteke, hala nola Ubuntu edo Debian.

Iturria: www.habr.com