O site está localizado em um VDS executando 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 era a capacidade de criar backups rapidamente com consumo mínimo de espaço adicional e recursos do sistema.
Não estamos falando de um instantâneo para restaurar rapidamente todo o sistema, mas de arquivos e do banco de dados e do histórico de alterações.
Dados iniciais:
- VDS na virtualização XEN;
- CentOS 7 OS;
- 1C-Bitrix: ambiente Web;
- Site baseado em "1C-Bitrix: Gerenciamento de sites", versão padrão;
- O tamanho do arquivo é 50 GB e aumentará;
- O tamanho do banco de dados é de 3 GB e aumentará.
Backup padrão integrado em 1C-Bitrix - excluído imediatamente. Só é adequado para pequenos sites, porque:
- , , , 50 .
- PHP, — , .
- 90 .
A solução oferecida pelo hoster é 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, então através de seu módulo de backup. Esta opção não é adequada devido ao uso do mesmo data center.
De todos os itens acima, 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;
- duplicidade de utilitário instalado;
- conta em Yandex.Cloud.
O backup incremental é um método em que apenas os dados alterados desde o último backup são arquivados.
duplicity é um utilitário de backup que usa algoritmos rsync e pode funcionar com o Amazon S3.
Yandex.Cloud vs Amazon S3
Não há diferença entre Yandex.Cloud e Amazon S3 neste caso. Yandex oferece suporte à parte principal da API do Amazon S3, então você pode trabalhar com ela usando as soluções disponíveis para trabalhar com S3. No meu caso, esse é o utilitário de duplicidade.
A principal vantagem do Yandex pode ser o pagamento em rublos; se houver muitos dados, não haverá vínculo com a taxa de câmbio. Em termos de velocidade, os centros de dados europeus da Amazon funcionam de forma compatível com os russos em Yandex, por exemplo, você pode usar Frankfurt. Eu usei o Amazon S3 anteriormente para tarefas semelhantes, agora decidi experimentar o Yandex.
Configurando Yandex.Cloud
1. Você precisa criar uma conta de faturamento em Yandex.Cloud. Para fazer isso, você precisa fazer login no Yandex.Cloud através da sua conta Yandex ou criar uma nova.
2. Crie uma "nuvem".

3. Crie um "Catálogo" na "Nuvem".

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

5. Crie chaves para a "Conta de serviço".

6. Guarde as chaves, pois elas serão necessárias no futuro.

7. Crie um "Balde" para o "Catálogo", ele conterá arquivos.

8. Recomendo definir um limite e escolher "Armazenamento refrigerado".

Configurando um backup agendado no servidor
Este guia pressupõe habilidades básicas de administração.
1. Instale o utilitário de duplicidade no VDS
yum install duplicity
2. Crie uma pasta para mysql dumps, 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 script:
#!`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 devem aparecer no "Balde".
`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 com a frequência necessária.
10 4,16 * * * `which bash` /backup_scripts/backup.sh
Recuperação de dados de Yandex.Cloud
1. Faça uma pasta para recovery / backup_restore
2. Faça um script bash para recovery /backup_scripts/restore.sh
Dou o exemplo mais popular de restauraçã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 cujo backup foi feito anteriormente.
Você pode fazer configurações mais detalhadas para atender às suas necessidades.
Desvantagem da 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 um problema, mas ao usar um canal protegido contra DDoS com uma classificação de taxa por dia, gostaria de poder definir um limite de 1-2 megabits.
Como uma conclusão
A reserva 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 no painel de controle de hospedagem ou no painel de administração do Bitrix, o que dá segurança adicional.
Com o resultado mais triste, você pode construir um novo servidor e implantar o site para qualquer data. Embora a funcionalidade mais solicitada seja a capacidade de se referir a um arquivo para uma data específica.
Você pode usar essa 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.