ProHoster > Blog > Administración > Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

Foi necesario facer unha copia de seguridade do sitio en 2C-Bitrix: Xestión do sitio 1 veces ao día (arquivos e base de datos mysql) e almacenar un historial de cambios durante 90 días.

O sitio está situado nun VDS que executa CentOS 7 con "1C-Bitrix: Web Environment" instalado. Ademais, fai unha copia de seguridade da configuración do SO.

Requisitos:

  • Frecuencia - 2 veces ao día;
  • Conserva copias dos últimos 90 días;
  • A posibilidade de obter ficheiros individuais para unha data específica, se é necesario;
  • A copia de seguridade debe almacenarse nun centro de datos que non sexa VDS;
  • A posibilidade de acceder á copia de seguridade desde calquera lugar (outro servidor, ordenador local, etc.).

Un punto importante foi a capacidade de crear rapidamente copias de seguridade cun consumo mínimo de espazo adicional e recursos do sistema.

Non se trata dunha instantánea para unha restauración rápida de todo o sistema, senón de ficheiros, a base de datos e o historial de cambios.

Datos iniciais:

  • VDS sobre virtualización XEN;
  • OS CentOS 7;
  • 1C-Bitrix: contorno web;
  • Sitio baseado en "1C-Bitrix: Xestión do sitio", versión estándar;
  • O tamaño do ficheiro é de 50 GB e crecerá;
  • O tamaño da base de datos é de 3 GB e crecerá.

Copia de seguranza estándar integrada en 1C-Bitrix - excluída inmediatamente. É axeitado só para sitios pequenos, porque:

  • Fai unha copia completa do sitio cada vez, respectivamente, cada copia ocupará tanto espazo como eu ocupe os ficheiros, no meu caso é de 50 GB.
  • A copia de seguridade realízase usando PHP, o que é imposible con tales volumes de ficheiros, sobrecargará o servidor e nunca rematará.
  • E, por suposto, non se pode falar de 90 días ao almacenar unha copia completa.

A solución que ofrece o host é un disco de copia de seguridade situado no mesmo centro de datos que o VDS, pero nun servidor diferente. Pode traballar co disco a través de FTP e usar os seus propios scripts, ou se ISPManager está instalado no VDS, a través do seu módulo de copia de seguridade. Esta opción non é adecuada debido ao uso do mesmo centro de datos.

De todo o anterior, a mellor opción para min é unha copia de seguridade incremental segundo o meu propio escenario en Yandex.Cloud (almacenamento de obxectos) ou Amazon S3 (servizo de almacenamento simple de Amazon).

Isto require:

  • acceso root a VDS;
  • utilidade de duplicidade instalada;
  • conta en Yandex.Cloud.

copia de seguridade incremental - un método no que só se arquivan os datos que cambiaron desde a última copia de seguridade.

duplicidade - unha utilidade de copia de seguridade que usa algoritmos rsync e pode funcionar con Amazon S3.

Yandex.Cloud vs Amazon S3

Non hai diferenza entre Yandex.Cloud e Amazon S3 neste caso para min. Yandex admite a parte principal da API de Amazon S3, polo que podes traballar con ela usando as solucións dispoñibles para traballar con S3. No meu caso, esta é a utilidade de duplicidade.

A principal vantaxe de Yandex pode ser o pago en rublos, se hai moitos datos, non haberá ligazón ao curso. En termos de velocidade, os centros de datos europeos de Amazon traballan en proporción aos rusos en Yandex, por exemplo, podes usar Frankfurt. Antes utilizaba Amazon S3 para tarefas similares, agora decidín probar Yandex.

Configurando Yandex.Cloud

1. Debes crear unha conta de facturación en Yandex.Cloud. Para iso, debes iniciar sesión en Yandex.Cloud a través da túa conta Yandex ou crear unha nova.

2. Crear nube.
Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

3. Na "Nube" crea un "Catálogo".
Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

4. Para o "Catálogo" cree unha "Conta de servizo".
Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

5. Para a "Conta de servizo" cree claves.
Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

6. Garda as chaves, necesitarás no futuro.
Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

7. Para o "Catálogo" crea un "Cubo", os ficheiros caerán nel.
Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

8. Recomendo establecer un límite e seleccionar "Almacenamento en frío".
Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

Configurar copias de seguridade programadas no servidor

Esta guía asume habilidades administrativas básicas.

1. Instale a utilidade de duplicidade no VDS

yum install duplicity

2. Cree un cartafol para vertedoiros de mysql, no meu caso é /backup_db na raíz VDS

3. Crea un cartafol para os scripts bash /backup_scripts e fai o primeiro script que fará unha copia de seguridade de /backup_scripts/backup.sh

Contido do guión:

#!`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. Execute o script por primeira vez e comprobe o resultado, os ficheiros deberían aparecer no Bucket.

`which bash` /backup_scripts/backup.sh

Copia de seguranza incremental de VDS cun sitio en 1C-Bitrix en Yandex.Cloud

5. Engade un script ao cron para que o usuario root se execute 2 veces ao día ou tantas veces como necesites.

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

Recuperación de datos de Yandex.Cloud

1. Fai un cartafol de restauración /backup_restore

2. Fai o script de restauración de bash /backup_scripts/restore.sh

Poño o exemplo máis solicitado de recuperar un ficheiro específico:

#!`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. Executa o script e agarda o resultado.

`which bash` /backup_scripts/backup.sh

No cartafol /backup_restore/ atoparás o ficheiro index.php que se incluíu anteriormente na copia de seguridade.

Podes facer axustes máis finos para satisfacer as túas necesidades.

menos duplicidade

A duplicidade ten un inconveniente: non hai forma de establecer un límite de uso da canle. Cunha canle normal, isto non crea ningún problema, pero cunha canle protexida por DDoS con facturación de velocidade por día, gustaríame poder establecer un límite de 1-2 megabits.

Como conclusión

A copia de seguranza en Yandex.Cloud ou Amazon S3 proporciona unha copia independente da configuración do sitio e do sistema operativo á que se pode acceder desde calquera outro servidor ou ordenador local. Ao mesmo tempo, esta copia non é visible nin no panel de control de hospedaxe nin no panel de administración de Bitrix, o que proporciona seguridade adicional.

No resultado máis desafortunado, podes construír un novo servidor e implementar o sitio para calquera data. Aínda que a funcionalidade máis solicitada será a posibilidade de acceder ao ficheiro para unha data concreta.

Podes usar esta técnica con calquera VDS ou servidores e sitios dedicados en calquera motor, non só 1C-Bitrix. O SO tamén pode ser distinto de CentOS, como Ubuntu ou Debian.

Fonte: www.habr.com

Engadir un comentario