🥇Backup VDS incrementale con un sito Web su 1C-Bitrix in Yandex.Cloud

Avevo bisogno di eseguire il backup del sito su “2C-Bitrix: Site Management” (file e database mysql) due volte al giorno e archiviare una cronologia delle modifiche per 1 giorni.

Il sito si trova su un VDS con sistema operativo CentOS 7 con 1C-Bitrix: ambiente Web installato. Inoltre, crea una copia di backup delle impostazioni del tuo sistema operativo.

requisiti:

Frequenza - 2 volte al giorno;
Conservare le copie degli ultimi 90 giorni;
La possibilità di ottenere singoli file per una data specifica, se necessario;
Il backup deve essere archiviato in un data center diverso da VDS;
La possibilità di accedere al backup da qualsiasi luogo (un altro server, computer locale, ecc.).

Un punto importante è stata la possibilità di creare rapidamente backup con un consumo minimo di spazio aggiuntivo e risorse di sistema.

Non si tratta di un'istantanea per ripristinare rapidamente l'intero sistema, ma di file, database e cronologia delle modifiche.

Contesto:

VDS sulla virtualizzazione XEN;
sistema operativo CentOS 7;
1C-Bitrix: ambiente Web;
Sito web basato su “1C-Bitrix: Site Management”, versione Standard;
La dimensione del file è 50 GB e aumenterà;
La dimensione del database è 3 GB e aumenterà.

Ho immediatamente escluso il backup standard integrato in 1C-Bitrix. È adatto solo per piccoli siti, perché:

Crea ogni volta una copia completa del sito, quindi ogni copia occuperà la stessa quantità di spazio occupata dai file, nel mio caso sono 50 GB.
Il backup viene eseguito utilizzando PHP, cosa impossibile con tali volumi di file, poiché sovraccaricherà il server e non verrà mai completato.
E, naturalmente, non si può parlare di 90 giorni quando si archivia una copia completa.

La soluzione offerta dall'hoster è un disco di backup situato nello stesso data center del VDS, ma su un server diverso. Puoi lavorare con il disco tramite FTP e utilizzare i tuoi script oppure, se ISPManager è installato sul VDS, tramite il suo modulo di backup. Questa opzione non è adatta a causa dell'utilizzo dello stesso data center.

Da tutto quanto sopra, la scelta migliore per me è un backup incrementale utilizzando il mio script in Yandex.Cloud (Object Storage) o Amazon S3 (Amazon Simple Storage Service).

Questo richiede:

accesso root a VDS;
utilità di duplicazione installata;
account in Yandex.Cloud.

Backup incrementale — un metodo in cui vengono archiviati solo i dati che sono cambiati dall'ultimo backup.

duplicità — un'utilità di backup che utilizza algoritmi rsync e può funzionare con Amazon S3.

Yandex.Cloud contro Amazon S3

In questo caso per me non c'è differenza tra Yandex.Cloud e Amazon S3. Yandex supporta la maggior parte dell'API Amazon S3, quindi puoi lavorarci utilizzando le soluzioni esistenti per lavorare con S3. Nel mio caso, questa è l'utilità di duplicità.

Il vantaggio principale di Yandex potrebbe essere il pagamento in rubli; se ci sono molti dati, non ci sarà alcun collegamento con il tasso di cambio. In termini di velocità, i data center europei di Amazon funzionano in modo paragonabile ai data center russi di Yandex; ad esempio, puoi utilizzare Francoforte. In precedenza utilizzavo Amazon S3 per attività simili, ora ho deciso di provare Yandex.

Configurazione di Yandex.Cloud

1. Devi creare un conto di pagamento in Yandex.Cloud. Per fare ciò, devi accedere a Yandex.Cloud tramite il tuo account Yandex o crearne uno nuovo.

2. Crea una "nuvola".

3. Nella “Cloud” crea un “Catalogo”.

4. Per il “Catalogo” creare un “Account di servizio”.

5. Creare chiavi per l'"Account di servizio".

6. Conserva le chiavi, ti serviranno in futuro.

7. Per la "Directory" crea un "Bucket", i file verranno inseriti in esso.

8. Consiglio di impostare un limite e di selezionare "Cold Storage".

Configurazione dei backup pianificati sul server

Questa guida presuppone competenze amministrative di base.

1. Installare l'utilità Duplicity sul VDS

yum install duplicity

2. Crea una cartella per i dump mysql, nel mio caso è /backup_db nella root VDS

3. Crea una cartella per gli script bash /backup_scripts e crea il primo script che eseguirà i backup /backup_scripts/backup.sh

Contenuti della sceneggiatura:

#!`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. Esegui lo script per la prima volta e controlla il risultato: i file dovrebbero apparire nel "Bucket".

`which bash` /backup_scripts/backup.sh

5. Aggiungi uno script a cron affinché l'utente root possa eseguirlo 2 volte al giorno o con la frequenza di cui hai bisogno.

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

Recupero dei dati da Yandex.Cloud

1. Crea una cartella di ripristino /backup_restore

2. Crea uno script bash per il ripristino /backup_scripts/restore.sh

Fornisco l'esempio più popolare di ripristino di un file specifico:

#!`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. Esegui lo script e attendi il risultato.

`which bash` /backup_scripts/backup.sh

Nella cartella /backup_restore/ troverai il file index.php di cui è stato precedentemente eseguito il backup.

Puoi apportare modifiche più precise in base alle tue esigenze.

Meno duplicazione

duplicity ha uno svantaggio: non è possibile impostare un limite di utilizzo del canale. Con un canale normale questo non crea problemi, ma quando si utilizza un canale protetto da DDoS con ricarica veloce al giorno, vorrei poter impostare un limite di 1-2 megabit.

Come conclusione

Il backup in Yandex.Cloud o Amazon S3 fornisce una copia indipendente delle impostazioni del sito e del sistema operativo a cui è possibile accedere da qualsiasi altro server o computer locale. Inoltre, questa copia non è visibile né nel pannello di controllo dell'hosting né nel pannello di amministrazione di Bitrix, il che garantisce ulteriore sicurezza.

Nel peggiore dei casi, puoi assemblare un nuovo server e implementare il sito in qualsiasi data. Sebbene la funzionalità più popolare sarà la possibilità di accedere a un file per una data specifica.

Puoi utilizzare questa tecnica con qualsiasi VDS o server e sito dedicati su qualsiasi motore, non solo 1C-Bitrix. Il sistema operativo potrebbe anche essere diverso da CentOS, come Ubuntu o Debian.

Fonte: habr.com

Backup VDS incrementale con un sito su 1C-Bitrix in Yandex.Cloud

Yandex.Cloud contro Amazon S3

Configurazione di Yandex.Cloud

Configurazione dei backup pianificati sul server

Recupero dei dati da Yandex.Cloud

Come conclusione

Aggiungi un commento Cancella risposta