Bitrix24 On-Premise: Estratégia de Backup e Disaster Recovery

Por Que o Bitrix24 On-Premise (Alaio) Exige um Plano de DR Sério

O Bitrix24 auto-hospedado não conta com nenhuma proteção em nuvem. Um único ataque de ransomware, uma corrupção de banco de dados ou uma atualização de SO malsucedida pode derrubar simultaneamente o CRM, a telefonia, as tarefas e as comunicações - tornando uma estratégia documentada de backup e DR a diferença entre uma restauração de duas horas e um desastre de duas semanas.

Quando você executa o Bitrix24 na própria infraestrutura, não há nenhuma rede de segurança em nuvem. Uma atualização de SO com falha, um banco de dados corrompido ou um incidente de ransomware pode tirar do ar o CRM, as tarefas, a telefonia e as comunicações internas - tudo ao mesmo tempo. Com base em nossa experiência de implementação, as causas mais comuns de perda de dados ou tempo de inatividade prolongado em portais auto-hospedados são:

• Atualizações não planejadas de SO ou módulos aplicadas diretamente no servidor de produção sem uma cópia de staging
• Corrupção de banco de dados - mesmo um portal de porte médio pode ter um banco de dados MySQL de 25-30 GB, e erros de InnoDB podem se propagar rapidamente
• Incidentes de segurança - portais executando ambientes web desatualizados acumulam vulnerabilidades que são ativamente exploradas
• Falha de hardware ou VPS sem nenhuma cópia dos dados em local externo

Uma estratégia documentada de backup e DR é a diferença entre uma restauração de duas horas e um desastre de duas semanas.

---

O Que Exatamente Precisa Ser Incluído no Backup

Um backup completo do Bitrix24 on-premise exige três componentes distintos - o banco de dados MySQL/MariaDB, todos os arquivos da aplicação em /home/bitrix/www/ e os arquivos de configuração do servidor - porque a ausência de qualquer um deles torna impossível uma restauração completa.

Um backup completo do Bitrix24 on-premise tem três componentes distintos. A ausência de qualquer um deles torna impossível uma restauração completa.

Componente	Localização típica	Observações
Banco de dados MySQL / MariaDB	Schema sitemanager (ou sitemanager0)	Contém todos os dados de CRM, tarefas, usuários e estado dos processos de negócio
Arquivos da aplicação	/home/bitrix/www/	Inclui /bitrix/, /local/, uploads e componentes personalizados
Configuração do servidor	/etc/nginx/, /etc/php.ini, /etc/my.cnf, entradas de cron	Necessários para reconstruir o ambiente exatamente como estava

Atenção ao código personalizado. Projetos que modificaram arquivos do núcleo do Bitrix24 - o que nossas auditorias de segurança ocasionalmente revelam, geralmente em uma pequena porcentagem do total de arquivos, mas em módulos críticos como CRM e IM - precisam ter esses arquivos capturados separadamente e documentados. Caso contrário, uma atualização os sobrescreverá silenciosamente.

Inclua também no backup:

• Arquivos de certificado SSL (ou a configuração de renovação do Let's Encrypt)
• Credenciais do relay SMTP e arquivos /home/bitrix/msmtp*.conf
• Quaisquer tarefas cron do usuário bitrix (/usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php)

---

Definindo as Metas de RPO e RTO

Para um portal Bitrix24 auto-hospedado de porte médio com CRM, telefonia e tarefas, o RPO recomendado é de 1-2 horas e o RTO é de 2 horas - o que exige backups incrementais ou em nível de log de transações, e não apenas dumps completos noturnos.

Antes de definir a frequência de backup, estabeleça dois parâmetros:

• RPO (Recovery Point Objective) - qual o volume de perda de dados aceitável. Para um CRM ativo com ligações de vendas, leads e atualizações de negócios acontecendo ao longo do dia, um RPO superior a algumas horas geralmente é inaceitável.
• RTO (Recovery Time Objective) - por quanto tempo a operação pode funcionar sem o portal. Para empresas que utilizam o Bitrix24 para telefonia, gestão de tarefas e comunicação com clientes, mesmo meio dia de inatividade tem impacto mensurável na receita.

Metas típicas para um portal auto-hospedado de porte médio:

Cenário	RPO Recomendado	RTO Recomendado
Uso somente de CRM	4-8 horas	4 horas
CRM + telefonia + tarefas	1-2 horas	2 horas
CRM + integração ERP (ex.: SAP)	30-60 minutos	1 hora

Atingir um RPO de 1 hora exige backups incrementais ou em nível de log de transações - não apenas dumps completos noturnos.

---

Arquitetura de Backup: Três Cópias, Duas Localizações

A regra 3-2-1, padrão do setor, exige 3 cópias dos dados em 2 localizações distintas com 1 cópia off-site ou air-gapped - implementada para o Bitrix24 como um backup local para restaurações rápidas, uma cópia remota em S3/NFS para falhas no servidor e uma cópia fria semanal para eventos de ransomware ou desastres no datacenter.

A regra 3-2-1, padrão do setor, se aplica diretamente aqui:

• 3 cópias dos dados
• 2 mídias ou localizações de armazenamento diferentes
• 1 cópia off-site ou air-gapped

Uma configuração prática para um portal Bitrix24 auto-hospedado. Um job de backup agendado produz um snapshot completo (dump do banco de dados + arquivo de arquivos + arquivos de configuração) armazenado localmente, depois sincronizado com um servidor de backup separado ou armazenamento de objetos (compatível com S3), com uma cópia periódica para armazenamento frio/off-site.

flowchart LR
    PROD[Production Server\nBitrix24 + MySQL]
    LOCAL[Local Backup\nSame datacenter]
    REMOTE[Remote Backup\nS3 / NFS / second VPS]
    OFFSITE[Off-site / Cold Copy\nRotated weekly]

    PROD -- "nightly full\n+ hourly DB dump" --> LOCAL
    LOCAL -- "daily sync" --> REMOTE
    REMOTE -- "weekly rotation" --> OFFSITE

Na prática, o backup local garante restaurações rápidas (em minutos), a cópia remota cobre falhas no nível do servidor e a cópia off-site protege contra eventos de ransomware ou falhas no datacenter.

---

Backup Nativo do Bitrix24 vs. Backup em Nível de SO

O backup nativo do Bitrix24 pelo painel administrativo é conveniente, mas grava no mesmo disco do servidor por padrão, compartilhando o mesmo domínio de falha da produção. Para portais com bancos de dados acima de 15-20 GB, backups por script em nível de SO utilizando Percona XtraBackup ou mariabackup são necessários para uma cobertura de DR confiável e sem bloqueio de tabelas.

O Bitrix24 inclui um módulo de backup nativo acessível pelo painel administrativo. Na implantação inicial do servidor, ele costuma ser configurado para gravar os backups no mesmo servidor que hospeda o portal. Isso satisfaz o requisito básico de "ter um backup" - mas não atende a um requisito real de DR, porque o backup e os dados de produção compartilham o mesmo disco e o mesmo domínio de falha.

Backup nativo do Bitrix24 (painel administrativo):

• Conveniente, não exige acesso SSH
• Cobre arquivos e banco de dados em um único arquivo
• O destino padrão é o servidor local - deve ser redirecionado ou complementado

Backup em nível de SO / por script:

• Controle total sobre frequência, compressão e retenção
• Permite executar mysqldump ou xtrabackup (para bancos de dados grandes) de forma agendada
• Possibilita o envio automático de arquivos criptografados para armazenamento remoto
• Captura os arquivos de configuração que a ferramenta nativa ignora

Para portais com bancos de dados acima de ~15-20 GB, o mysqldump se torna lento. O Percona XtraBackup (ou mariabackup) suporta backups físicos a quente sem bloquear tabelas - um requisito importante para portais que operam 24/7.

---

O Protocolo de Backup Pré-Atualização

Toda atualização de módulo ou núcleo do Bitrix24 deve ser precedida por um dump completo do banco de dados, arquivo dos arquivos, snapshot de configuração e uma implantação validada em staging - um ciclo que acrescenta aproximadamente meio dia útil, mas custa muito menos do que uma operação de recuperação após uma atualização malsucedida em produção.

Um procedimento que nossas equipes de projeto executam em toda atualização de módulo ou núcleo é um backup completo pré-alteração. A sequência documentada é:

1. Dump completo do banco de dados - capturar o estado atual do sitemanager
2. Arquivo completo dos arquivos - tar/gz de /home/bitrix/www/
3. Snapshot de configuração - cópia dos arquivos de configuração de nginx, PHP e MySQL
4. Implantação de uma cópia em staging - inicializar o backup em um servidor separado e validar que ele sobe corretamente
5. Executar a atualização primeiro em staging - testar todas as funções críticas (registros de CRM, sincronização de tarefas, integrações, processos de negócio, itens de menu personalizados)
6. Aplicar em produção - somente após o staging confirmar que não há regressões

Essa sequência é inegociável quando o portal possui código personalizado em /local/ ou arquivos do núcleo modificados, porque as atualizações de módulos sobrescreverão alterações em /bitrix/php_interface/ - razão pela qual o código personalizado deve ser migrado para /local/ antes de qualquer atualização.

Para referência: em um projeto típico, o ciclo completo de backup e staging acrescenta aproximadamente meio dia útil a qualquer atualização significativa. É muito mais barato do que uma operação de recuperação.

---

Proteções de Segurança que Garantem seus Backups

Um backup não tem valor se o ransomware o alcança junto com os dados de produção. A proteção eficaz exige acesso administrativo restrito por IP, 2FA em todas as contas de administrador, ambiente web atualizado e arquivos de backup armazenados fora do servidor com credenciais separadas que a chave SSH de produção não consegue acessar.

Um backup não tem valor se o atacante que criptografou seu servidor de produção também criptografou seu backup. Algumas medidas de proteção reduzem esse risco:

• Restringir o acesso ao painel administrativo por whitelist de IP - impede acesso não autorizado à interface de download de backups
• Desabilitar a exibição de erros PHP (display_errors, display_startup_errors desativados em php.ini) - evita a exposição de caminhos do servidor que auxiliam ataques direcionados
• Habilitar HSTS e forçar HTTPS - reduz o risco de interceptação durante downloads de backup
• Habilitar autenticação de dois fatores (2FA) para todas as contas de administrador - o Bitrix24 suporta OTP por meio do próprio aplicativo
• Manter o ambiente web atualizado - nossas auditorias de segurança identificaram portais ainda executando ambientes web várias versões principais abaixo da recomendação atual, com SO, nginx, Apache, PHP e MySQL todos desatualizados ao mesmo tempo. Cada componente desatualizado é um vetor de ataque em potencial
• Manter uma lista de bloqueio de IPs no firewall - atualizada regularmente com IPs a partir dos quais padrões de ataque são detectados
• Armazenar os arquivos de backup fora do servidor com um conjunto separado de credenciais - o armazenamento de backup não deve ser acessível com a mesma chave SSH do servidor de produção

Veja também: Self-Hosted CRM: Why Choose Bitrix24 On-Premise for Data Sovereignty para uma discussão mais ampla sobre as diferenças entre implantação em nuvem e on-premise.

---

Simulações de Restauração: Testando se a Recuperação Funciona de Verdade

Um backup que nunca foi testado é uma hipótese, não uma garantia - agende simulações de restauração trimestrais em um servidor limpo, teste todas as funções críticas do Bitrix24, incluindo CRM, sincronização com SAP, SMTP e chats via Push & Pull, e registre o RTO real para verificar se ele atende à sua meta.

A maioria das equipes faz backups com disciplina, mas nunca realiza uma restauração. Um backup que nunca foi testado é uma hipótese, não uma garantia. Agende simulações de restauração pelo menos trimestralmente:

1. Provisionar um servidor limpo (ou snapshot de VM) que espelhe as especificações de produção
2. Restaurar o banco de dados a partir do backup mais recente - verificar a contagem de registros nas principais tabelas do CRM
3. Restaurar os arquivos da aplicação - confirmar que os componentes personalizados e o código em /local/ estão presentes
4. Restaurar a configuração - aplicar as configurações de nginx, PHP e MySQL
5. Executar a verificação de sistema do Bitrix24 - a ferramenta de diagnóstico nativa sinalizará erros de estrutura do banco de dados, incompatibilidades de ambiente e problemas de configuração
6. Testar as funções críticas - criar um lead de teste, atualizar um negócio, verificar a sincronização com SAP se aplicável, confirmar o envio de e-mail via relay SMTP e verificar se o Push & Pull (chats) está ativo
7. Medir o RTO real - registrar quanto tempo levou o processo completo

Documente o resultado de cada simulação. Se o RTO real superar consistentemente a sua meta, a arquitetura de backup precisa ser revisada - seja com armazenamento mais rápido, um servidor warm standby ou uma redução do escopo do que é restaurado na primeira etapa.

---

Lacunas Comuns em Implantações On-Premise

As auditorias técnicas de portais Bitrix24 auto-hospedados revelam com mais frequência: backups armazenados apenas no servidor de produção, dumps de banco de dados inconsistentes sem o uso do XtraBackup, períodos de retenção de apenas 3-5 dias e nenhum procedimento de restauração documentado - lacunas que se agravam porque portais com proteção insuficiente têm mais chances de precisar de recuperação e menos chances de se recuperar com sucesso.

Com base em nossas auditorias técnicas de portais Bitrix24 auto-hospedados, as lacunas de backup e DR mais frequentemente encontradas são:

• Backups armazenados apenas no servidor de produção (sem cópia off-site)
• Backups de banco de dados realizados sem bloqueio ou sem o uso do XtraBackup - resultando em dumps inconsistentes em portais com alto volume de acessos
• Nenhum procedimento de restauração documentado - a equipe sabe que os backups existem, mas ninguém sabe como utilizá-los
• Tamanho do log do InnoDB muito pequeno (innodb_log_file_size = 64 MB é uma configuração incorreta comum em instalações legadas), o que afeta tanto o desempenho quanto a recuperação após falhas
• Query cache ainda habilitado - descontinuado no MySQL 8.x e pode causar corrupção de cache
• local_infile habilitado - um risco de segurança que também indica que a configuração nunca foi revisada
• Retenção de backup muito curta (3-5 dias), insuficiente para detectar uma corrupção que passou despercebida por uma semana

Essas questões se agravam mutuamente: um portal que não foi adequadamente protegido tem mais chances de precisar de recuperação, e um portal cujos backups nunca foram validados tem menos chances de se recuperar com sucesso quando isso ocorrer.

Se sua equipe está planejando a migração de um CRM em nuvem para uma implantação Bitrix24 auto-hospedada, a estratégia de backup deve ser definida antes da migração - e não depois. Consulte How to Migrate from HubSpot to Bitrix24: Step-by-Step Plan e Pipedrive to Bitrix24 Migration: What Changes and How to Move Your Data para considerações sobre a fase de migração.

Para uma visão geral do escopo e dos prazos de implementação, Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects aborda como a configuração de backup se encaixa no plano geral do projeto.

---

Trabalhando com um parceiro na auto-hospedagem. Quer o controle do Bitrix24 auto-hospedado sem precisar gerenciar o servidor você mesmo? O ACP Group pode implantá-lo e operá-lo para você - veja managed self-hosted Bitrix24, support & maintenance plans ou solicite um turnkey deployment quote.