ProHoster > Blog > administración > Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

Fue necesario para mí hacer una copia de seguridad del sitio en 2C-Bitrix: Administración del sitio 1 veces al día (archivos y base de datos MySQL) y almacenar un historial de cambios durante 90 días.

El sitio está ubicado en un VDS que ejecuta CentOS 7 con "1C-Bitrix: Web Environment" instalado. Además, haga una copia de seguridad de la configuración del sistema operativo.

requisitos:

  • Frecuencia: 2 veces al día;
  • Guarde copias de los últimos 90 días;
  • La posibilidad de obtener archivos individuales para una fecha específica, si es necesario;
  • La copia de seguridad debe almacenarse en un centro de datos que no sea VDS;
  • La capacidad de acceder a la copia de seguridad desde cualquier lugar (otro servidor, computadora local, etc.).

Un punto importante fue la capacidad de crear copias de seguridad rápidamente con un consumo mínimo de espacio adicional y recursos del sistema.

No se trata de una instantánea para una restauración rápida de todo el sistema, sino de archivos, bases de datos y el historial de cambios.

Antecedentes:

  • VDS sobre virtualización XEN;
  • SO CentOS 7;
  • 1C-Bitrix: entorno web;
  • Sitio basado en "1C-Bitrix: Site Management", versión estándar;
  • El tamaño del archivo es de 50 GB y irá creciendo;
  • El tamaño de la base de datos es de 3 GB y seguirá creciendo.

Copia de seguridad estándar integrada en 1C-Bitrix: excluida de inmediato. Es adecuado sólo para sitios pequeños porque:

  • Hace una copia completa del sitio cada vez, respectivamente, cada copia ocupará tanto espacio como yo ocupo los archivos, en mi caso son 50 GB.
  • La copia de seguridad se realiza mediante PHP, lo cual es imposible con tales volúmenes de archivos, sobrecargará el servidor y nunca terminará.
  • Y, por supuesto, no se puede hablar de 90 días para almacenar una copia completa.

La solución que ofrece el proveedor de alojamiento es un disco de respaldo ubicado en el mismo centro de datos que el VDS, pero en un servidor diferente. Puede trabajar con el disco a través de FTP y utilizar sus propios scripts, o si ISPManager está instalado en el VDS, a través de su módulo de copia de seguridad. Esta opción no es adecuada debido al uso del mismo centro de datos.

De todo lo anterior, la mejor opción para mí es una copia de seguridad incremental según mi propio escenario en Yandex.Cloud (Object Storage) o Amazon S3 (Amazon Simple Storage Service).

Esto requiere:

  • acceso root a VDS;
  • utilidad de duplicidad instalada;
  • cuenta en Yandex.Cloud.

respaldo incremental - un método en el que sólo se archivan los datos que han cambiado desde la última copia de seguridad.

duplicidad - una utilidad de copia de seguridad que utiliza algoritmos rsync y puede funcionar con Amazon S3.

Yandex.Cloud frente a Amazon S3

Para mí, en este caso no hay diferencia entre Yandex.Cloud y Amazon S3. Yandex admite la parte principal de la API de Amazon S3, por lo que puede trabajar con ella utilizando las soluciones disponibles para trabajar con S3. En mi caso, esta es la utilidad de duplicidad.

La principal ventaja de Yandex puede ser el pago en rublos; si hay muchos datos, no habrá ningún enlace al curso. En términos de velocidad, los centros de datos europeos de Amazon funcionan a la par de los rusos en Yandex, por ejemplo, puedes utilizar Frankfurt. Anteriormente usaba Amazon S3 para tareas similares, ahora decidí probar Yandex.

Configurar Yandex.Cloud

1. Debe crear una cuenta de facturación en Yandex.Cloud. Para hacer esto, debe iniciar sesión en Yandex.Cloud a través de su cuenta Yandex o crear una nueva.

2. Crear nube.
Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

3. En la "Nube" crea un "Catálogo".
Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

4. Para el "Catálogo" cree una "Cuenta de servicio".
Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

5. Para la "Cuenta de servicio", cree claves.
Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

6. Guarde las claves, las necesitará en el futuro.
Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

7. Para el "Catálogo", cree un "Depósito", los archivos caerán en él.
Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

8. Recomiendo establecer un límite y seleccionar "Almacenamiento en frío".
Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

Configurar copias de seguridad programadas en el servidor

Esta guía asume habilidades administrativas básicas.

1. Instale la utilidad de duplicidad en el VDS

yum install duplicity

2. Cree una carpeta para volcados de mysql, en mi caso es /backup_db en la raíz del VDS

3. Cree una carpeta para scripts bash /backup_scripts y cree el primer script que realizará la copia de seguridad /backup_scripts/backup.sh

Contenido del 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. Ejecute el script por primera vez y verifique el resultado; los archivos deberían aparecer en el depósito.

`which bash` /backup_scripts/backup.sh

Copia de seguridad incremental de VDS con un sitio en 1C-Bitrix en Yandex.Cloud

5. Agregue un script a cron para que el usuario root lo ejecute 2 veces al día o con la frecuencia que necesite.

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

Recuperación de datos de Yandex.Cloud

1. Crear una carpeta de restauración /backup_restore

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

Doy el ejemplo más solicitado de recuperación de un archivo 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. Ejecute el script y espere el resultado.

`which bash` /backup_scripts/backup.sh

En la carpeta /backup_restore/ encontrará el archivo index.php que se incluyó previamente en la copia de seguridad.

Puede realizar ajustes más precisos para satisfacer sus necesidades.

menos duplicidad

La duplicidad tiene un inconveniente: no hay forma de establecer un límite de uso del canal. Con un canal normal, esto no crea ningún problema, pero con un canal protegido contra DDoS con facturación de velocidad por día, me gustaría poder establecer un límite de 1-2 megabits.

Como conclusión

La copia de seguridad en Yandex.Cloud o Amazon S3 proporciona una copia independiente del sitio y la configuración del sistema operativo a la que se puede acceder desde cualquier otro servidor o computadora local. Al mismo tiempo, esta copia no es visible ni en el panel de control del hosting ni en el panel de administración de Bitrix, lo que proporciona seguridad adicional.

En el resultado más desafortunado, puede crear un nuevo servidor e implementar el sitio en cualquier fecha. Aunque la funcionalidad más solicitada será la posibilidad de acceder al expediente de una fecha concreta.

Puede utilizar esta técnica con cualquier VDS o servidor y sitio dedicado en cualquier motor, no solo 1C-Bitrix. El sistema operativo también puede ser distinto de CentOS, como Ubuntu o Debian.

Fuente: habr.com

Añadir un comentario