Por Que o Backup On-Premise É Diferente do Cloud
No Bitrix24 self-hosted, diferentemente da versão cloud, toda a responsabilidade de backup recai sobre o administrador: agendamento, retenção, cópia offsite e testes de restore devem cobrir 5 componentes críticos — banco de dados, arquivos, uploads, configurações de sistema e parâmetros do servidor.
Na versão cloud do Bitrix24, a Bitrix faz backups automáticos da infraestrutura. Na versão self-hosted (on-premise), toda a camada de backup — agendamento, retenção, offsite, testes de restore — é responsabilidade do administrador.
Os componentes que precisam ser cobertos são:
| Componente | O que proteger | Risco se perder |
|---|---|---|
| Banco de dados MySQL/MariaDB | Todos os registros de CRM, tarefas, chats | Perda total de dados operacionais |
Diretório de arquivos /bitrix/ |
Código, módulos, configurações | Portal inoperante após restore do BD |
Uploads e disco (/upload/) |
Documentos, gravações de chamadas, imagens | Perda de histórico de arquivos |
Configurações de sistema (.settings.php, .htaccess, SMTP) |
Credenciais de banco, regras de reescrita | Reinstalação manual necessária |
| Configurações do servidor (nginx/Apache, PHP, MySQL) | Parâmetros tuned para produção | Degradação de performance pós-restore |
Com o Bitrix24 on-premise, a implantação inclui a configuração inicial de backups locais no próprio servidor — mas isso cobre apenas o cenário mais básico. Uma estratégia de DR robusta vai além.
Definindo RPO e RTO para o Seu Ambiente
RPO e RTO variam conforme o porte: operações com até 50 usuários toleram RPO de 24h e RTO de 8h, enquanto ambientes com 200+ usuários críticos exigem RPO de 1 hora e RTO de 30 a 60 minutos, demandando automação de restore e servidor de standby.
Antes de escolher ferramentas, defina os seus objetivos de recuperação:
- RPO (Recovery Point Objective): quanto de dados você pode perder? Se o RPO for 4 horas, backups a cada 4 horas são o mínimo.
- RTO (Recovery Time Objective): em quanto tempo o portal precisa estar de volta? Um RTO de 2 horas exige automação de restore e servidor de standby.
Referências práticas por porte:
| Porte da operação | RPO recomendado | RTO aceitável |
|---|---|---|
| Até 50 usuários, uso interno | 24 horas | 8 horas |
| 50–200 usuários, equipe de vendas ativa | 4–8 horas | 2–4 horas |
| 200+ usuários, operação crítica | 1 hora | 30–60 minutos |
Para operações críticas, considere complementar o backup com uma configuração de alta disponibilidade em cluster que reduz o RTO para minutos.
Arquitetura Recomendada de Backup
A estratégia ideal opera em 3 camadas: backup local diário com retenção de 7 dias, cópia offsite semanal em S3 ou NAS remoto com retenção de 4 semanas, e arquivo mensal por 12 meses — complementada por snapshots de VM a cada 4 horas para RTO mínimo.
O diagrama abaixo descreve o fluxo completo de uma estratégia de backup em três camadas para o Bitrix24 on-premise: backup local no servidor de produção, cópia offsite para armazenamento secundário e snapshot para recuperação rápida.
flowchart LR
A[Servidor Bitrix24\nProdução] --> B[Backup Local\nDiário - 7 dias]
B --> C[Armazenamento Offsite\nS3 / NAS Remoto\nSemanal - 4 semanas]
C --> D[Arquivo Mensal\n12 meses]
A --> E[Snapshot de VM\nA cada 4h]
E --> F[Servidor de Standby\nRestore rápido]
F --> G[Teste de Restore\nMensal automatizado]
Camada 1 — Backup local diário: cópia do banco de dados (dump mysqldump ou xtrabackup) e dos arquivos. Retenção de 7 dias no mesmo servidor ou em volume separado.
Camada 2 — Offsite semanal: transferência automática para armazenamento de objeto (compatível com S3) ou NAS em localização distinta. Retenção de 4 semanas. Isso protege contra falha total do servidor de produção.
Camada 3 — Arquivo mensal: cópias mensais com retenção de 12 meses para fins de auditoria, conformidade com leis locais de proteção de dados e recuperação de dados históricos excluídos acidentalmente.
O Que Fazer Backup: Lista Técnica Detalhada
O backup completo do Bitrix24 on-premise deve cobrir dump do banco com --single-transaction, o diretório /home/bitrix/www/, uploads, configurações de nginx/Apache e PHP, certificados SSL e módulos de segurança — bancos acima de 20 GB exigem xtrabackup para evitar impacto em produção.
Banco de Dados
# Dump completo com single-transaction para consistência
mysqldump --single-transaction --routines --triggers \
-u bitrix0 -p sitemanager | gzip > /backup/db_$(date +%Y%m%d_%H%M).sql.gz
- Use
--single-transactionpara evitar locks durante o dump - Em bancos acima de 20 GB, prefira
xtrabackuppara backups físicos sem impacto em produção - Verifique a integridade do dump com
mysqlcheckperiodicamente — em projetos de migração de servidor, erros de estrutura de banco são comuns e devem ser corrigidos antes de qualquer restore
Sistema de Arquivos
Arquivos essenciais para backup completo:
- /home/bitrix/www/ — instalação completa do Bitrix24
- /home/bitrix/www/bitrix/.settings.php — configuração de conexão ao banco
- /home/bitrix/www/upload/ — arquivos enviados pelos usuários
- /etc/nginx/ ou /etc/apache2/ — configuração do servidor web
- /etc/php/ — parâmetros PHP ajustados para produção (InnoDB log size, query cache, etc.)
- Configuração de SMTP (/etc/msmtprc ou equivalente)
Certificados e Segurança
- Certificado SSL (Let's Encrypt renova automaticamente, mas inclua o
certbotna checklist de DR) - Listas de IPs autorizados ao painel administrativo
- Configurações do módulo de Proteção Proativa
Estratégia de Retenção e Política de Versionamento
A política de retenção recomendada combina 4 frequências: incremental a cada 4–6h por 48h no servidor local, full diário por 7 dias em local e offsite, semanal por 4 semanas em S3 ou NAS, e mensal por 12 meses em armazenamento frio — equilibrando proteção e custo de armazenamento.
Uma política de retenção equilibrada — sem consumir armazenamento excessivo:
| Frequência | Onde armazenar | Retenção |
|---|---|---|
| A cada 4–6 horas (incremental) | Local (servidor) | 48 horas |
| Diário (full) | Local + offsite | 7 dias |
| Semanal | Offsite (S3/NAS) | 4 semanas |
| Mensal | Offsite frio / tape | 12 meses |
Para o dimensionamento correto do armazenamento, consulte o guia de hardware para Bitrix24 self-hosted — o volume de uploads cresce rapidamente em portais com mais de 100 usuários.
Procedimento de Disaster Recovery: Passo a Passo
O procedimento de DR envolve 9 etapas sequenciais — do provisionamento do servidor ao redirecionamento de DNS — e pode ser concluído em 2 a 4 horas em condições controladas, com backup atualizado e servidor de standby pré-configurado.
O plano de DR deve ser documentado e testado, não apenas planejado. Em projetos de migração de servidor on-premise, o processo típico segue estas etapas:
- Provisionar o novo servidor com os mesmos requisitos de SO, PHP e MySQL da produção
- Restaurar o banco de dados a partir do dump mais recente (
mysql -u root -p sitemanager < dump.sql) - Sincronizar os arquivos do backup (
rsyncou descompactar o arquivo) - Restaurar as configurações (
.settings.php, nginx/Apache, PHP.ini) - Verificar a integridade do banco — corrigir automaticamente erros de estrutura e confirmar zero erros críticos
- Configurar SSL e redirecionar HTTP → HTTPS
- Testar funcionalidades críticas: login de usuários, CRM, chats (Push & Pull), integrações
- Redirecionar DNS para o IP do novo servidor
- Validar com usuários-piloto antes de abrir para todos
Em condições controladas, com backup atualizado e servidor de standby pré-configurado, este processo pode ser concluído em 2 a 4 horas.
Para ambientes que migraram da nuvem para o on-premise, o plano de migração cloud para self-hosted documenta cuidados adicionais de backup durante a transição.
Erros Mais Comuns em Estratégias de Backup do Bitrix24
Os 6 erros mais recorrentes em implantações on-premise são: backup apenas do banco sem arquivos, ausência de cópia offsite, nunca testar o restore, ignorar configurações de servidor, não fazer backup antes de atualizações e armazenar arquivos de backup sem criptografia ou controle de acesso.
Com base em nossa experiência em projetos de implantação e migração, estes são os erros recorrentes:
- Backup só do banco, sem os arquivos: o restore do banco sem os arquivos de upload resulta em portal funcional mas com histórico de documentos perdido
- Backup local sem cópia offsite: falha no servidor de produção elimina o backup junto com os dados
- Nunca testar o restore: backups corrompidos ou incompletos só são descobertos na hora da emergência
- Ignorar configurações de servidor: após restore, parâmetros como
innodb_log_file_sizee desativação dequery_cacheprecisam ser reaplicados manualmente - Esquecer o backup antes de atualizações: antes de qualquer atualização de versão do Bitrix24, um backup completo é obrigatório
- Credenciais de acesso ao backup sem controle de acesso: arquivos de backup contêm senhas em texto em
.settings.php— proteja com criptografia e restrição de acesso
Para uma visão completa das vulnerabilidades que o backup ajuda a mitigar, veja o checklist de hardening do Bitrix24 self-hosted.
Ferramentas e Automação Recomendadas
As principais ferramentas de backup para Bitrix24 on-premise são: mysqldump com cron para bancos até 5 GB, Percona XtraBackup para bancos grandes sem lock, Restic ou Borg para arquivos incrementais com deduplicação e suporte a S3, e snapshots de VM para RTO mínimo em ambientes virtualizados.
Opções de automação de backup
| Ferramenta | Uso ideal | Observação |
|---|---|---|
mysqldump + cron |
Ambientes pequenos, até ~5 GB de BD | Simples, sem dependências |
| Percona XtraBackup | Bancos grandes, backup físico sem lock | Requer instalação adicional |
| Restic / Borg | Backup incremental de arquivos com deduplicação | Suporte a S3, SFTP, B2 |
| Snapshots de VM (VMware, Proxmox, KVM) | Ambientes virtualizados | RTO muito baixo; cuidado com consistência de BD |
| Velero (Kubernetes) | Deploy containerizado do Bitrix24 | Backup de manifests + volumes |
Automação de teste de restore
Um script simples de validação semanal deve:
1. Restaurar o último backup em ambiente de staging isolado
2. Verificar se o portal carrega e se o login funciona
3. Confirmar que o banco passa no teste de integridade (mysqlcheck --all-databases)
4. Enviar relatório por e-mail ao administrador
Considerações de Conformidade e Soberania de Dados
Empresas que adotam o Bitrix24 on-premise por soberania de dados devem garantir que o destino offsite esteja na jurisdição correta, que backups sejam criptografados em repouso e em trânsito, e que a política de retenção atenda à LGPD no Brasil ou ao GDPR na Europa.
Empresas que adotam o Bitrix24 on-premise frequentemente o fazem por requisitos de soberania de dados — manter todo o histórico de clientes dentro da própria infraestrutura ou em data center local. Isso impacta diretamente a estratégia de backup:
- O destino offsite (S3, NAS) deve estar na mesma jurisdição ou em provedor contratualmente adequado às leis locais de proteção de dados
- Backups devem ser criptografados em repouso e em trânsito
- A política de retenção deve ser alinhada com o período exigido pela legislação local (LGPD no Brasil, GDPR na Europa)
- Logs de acesso ao sistema de backup devem ser mantidos para fins de auditoria
Para empresas com requisitos mais rigorosos, a combinação de backup offsite com uma arquitetura de alta disponibilidade garante tanto a conformidade quanto a resiliência operacional. Veja também como o Bitrix24 on-premise se posiciona no contexto de conformidade com GDPR para empresas europeias.