🥇Backup VDS incremental com um site em 1C-Bitrix em Yandex.Cloud

Foi necessário fazer backup do site em 2C-Bitrix: Site Management 1 vezes ao dia (arquivos e banco de dados mysql) e armazenar um histórico de alterações por 90 dias.

O site está localizado em um VDS rodando CentOS 7 com "1C-Bitrix: Web Environment" instalado. Além disso, faça uma cópia de backup das configurações do sistema operacional.

Requisitos:

Frequência – 2 vezes ao dia;
Guarde cópias dos últimos 90 dias;
A capacidade de obter arquivos individuais para uma data específica, se necessário;
O backup deve ser armazenado em um data center diferente do VDS;
A capacidade de acessar o backup de qualquer lugar (outro servidor, computador local, etc.).

Um ponto importante foi a capacidade de criar backups rapidamente com consumo mínimo de espaço adicional e recursos do sistema.

Não se trata de um instantâneo para uma restauração rápida de todo o sistema, mas de arquivos, do banco de dados e do histórico de alterações.

Linha de base:

VDS em virtualização XEN;
SO CentOS 7;
1C-Bitrix: Ambiente Web;
Site baseado em "1C-Bitrix: Site Management", versão padrão;
O tamanho do arquivo é de 50 GB e aumentará;
O tamanho do banco de dados é de 3 GB e aumentará.

Backup padrão integrado ao 1C-Bitrix - excluído imediatamente. É adequado apenas para sites pequenos porque:

Faz uma cópia completa do site a cada vez, respectivamente, cada cópia ocupará tanto espaço quanto eu ocupo os arquivos, no meu caso são 50 GB.
O backup é feito em PHP, o que é impossível com tantos volumes de arquivos, vai sobrecarregar o servidor e nunca vai acabar.
E, claro, não se pode falar em 90 dias para armazenar uma cópia completa.

A solução que o hoster oferece é um disco de backup localizado no mesmo data center do VDS, mas em um servidor diferente. Você pode trabalhar com o disco via FTP e usar seus próprios scripts, ou se o ISPManager estiver instalado no VDS, através de seu módulo de backup. Esta opção não é adequada devido ao uso do mesmo data center.

De tudo isso, a melhor escolha para mim é um backup incremental de acordo com meu próprio cenário em Yandex.Cloud (Object Storage) ou Amazon S3 (Amazon Simple Storage Service).

Isto exige:

acesso root ao VDS;
utilitário de duplicidade instalado;
conta no Yandex.Cloud.

backup incremental - um método no qual apenas os dados que foram alterados desde o último backup são arquivados.

duplicidade - um utilitário de backup que usa algoritmos rsync e pode funcionar com Amazon S3.

Yandex.Cloud versus Amazon S3

Não há diferença entre Yandex.Cloud e Amazon S3 neste caso para mim. Yandex oferece suporte à parte principal da API Amazon S3, para que você possa trabalhar com ela usando as soluções disponíveis para trabalhar com S3. No meu caso, este é o utilitário de duplicidade.

A principal vantagem do Yandex pode ser o pagamento em rublos; se houver muitos dados, não haverá link para o curso. Em termos de velocidade, os data centers europeus da Amazon funcionam de forma proporcional aos russos no Yandex, por exemplo, você pode usar Frankfurt. Anteriormente, usei o Amazon S3 para tarefas semelhantes, agora decidi experimentar o Yandex.

Configurando Yandex.Cloud

1. Você precisa criar uma conta de faturamento no Yandex.Cloud. Para fazer isso, você precisa fazer login no Yandex.Cloud por meio de sua conta Yandex ou criar uma nova.

2. Crie nuvem.

3. Na “Nuvem” crie um “Catálogo”.

4. Para o "Catálogo" crie uma "Conta de serviço".

5. Para a "Conta de serviço" crie chaves.

6. Guarde as chaves, você precisará delas no futuro.

7. Para o "Catálogo" crie um "Bucket", os arquivos cairão nele.

8. Eu recomendo definir um limite e selecionar "Armazenamento frio".

Configurando backups agendados no servidor

Este guia pressupõe habilidades administrativas básicas.

1. Instale o utilitário de duplicidade no VDS

yum install duplicity

2. Crie uma pasta para dumps mysql, no meu caso é /backup_db na raiz do VDS

3. Crie uma pasta para scripts bash /backup_scripts e faça o primeiro script que fará backup de /backup_scripts/backup.sh

Conteúdo do roteiro:

#!`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 pela primeira vez e verifique o resultado, os arquivos deverão aparecer no Bucket.

`which bash` /backup_scripts/backup.sh

5. Adicione um script ao cron para que o usuário root seja executado 2 vezes ao dia ou quantas vezes você precisar.

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

Recuperação de dados do Yandex.Cloud

1. Crie uma pasta de restauração /backup_restore

2. Faça o script de restauração bash /backup_scripts/restore.sh

Dou o exemplo mais solicitado de recuperação de um arquivo 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. Execute o script e aguarde o resultado.

`which bash` /backup_scripts/backup.sh

Na pasta /backup_restore/ você encontrará o arquivo index.php que foi incluído anteriormente no backup.

Você pode fazer ajustes mais precisos para atender às suas necessidades.

menos duplicidade

A duplicidade tem uma desvantagem: não há como definir um limite de uso do canal. Com um canal normal, isso não cria problemas, mas com um canal protegido contra DDoS com faturamento de velocidade por dia, gostaria de poder definir um limite de 1 a 2 megabits.

Como uma conclusão

O backup no Yandex.Cloud ou Amazon S3 fornece uma cópia independente do site e das configurações do sistema operacional que pode ser acessada de qualquer outro servidor ou computador local. Ao mesmo tempo, esta cópia não é visível nem no painel de controle da hospedagem nem no painel de administração do Bitrix, o que fornece segurança adicional.

Na pior das hipóteses, você pode construir um novo servidor e implantar o site em qualquer data. Embora a funcionalidade mais solicitada seja a possibilidade de acessar o arquivo para uma data específica.

Você pode usar esta técnica com qualquer VDS ou servidores e sites dedicados em qualquer mecanismo, não apenas 1C-Bitrix. O sistema operacional também pode ser diferente do CentOS, como Ubuntu ou Debian.

Fonte: habr.com

Backup incremental de VDS com um site em 1C-Bitrix em Yandex.Cloud

Yandex.Cloud versus Amazon S3

Configurando Yandex.Cloud

Configurando backups agendados no servidor

Recuperação de dados do Yandex.Cloud

Como uma conclusão

Adicionar um comentário cancelar resposta