Todas as bases de dados Odoo acabam por se tornar a única fonte de verdade de uma empresa: faturas, níveis de stock, dados para o processamento salarial, histórico de clientes e documentos assinados estão todos lá. Perdê-la, ou repor uma cópia incompleta, pode parar a operação durante dias. Ainda assim, muitas empresas só descobrem as falhas da sua abordagem às cópias de segurança no dia em que precisam delas.
Este artigo percorre o essencial da gestão de bases de dados, das cópias de segurança e da recuperação de desastres no Odoo 19 Enterprise, com notas sobre as diferenças nas instalações Community alojadas internamente. Destina-se a empresários, diretores financeiros e responsáveis de TI que precisam de uma visão clara sem lerem todas as páginas técnicas.
Uma nota sobre as fontes: este guia segue a documentação oficial do Odoo para a versão 19. As plataformas de alojamento e as suas opções evoluem, por isso confirme cada passo numa base de dados de teste e face à documentação oficial atual antes de confiar nele em produção.
O que contém uma cópia de segurança completa do Odoo
Uma base de dados Odoo não é apenas uma base de dados PostgreSQL. Os anexos, como documentos carregados, imagens e outros conteúdos binários, são guardados como ficheiros naquilo a que o Odoo chama o filestore, e o Odoo regula o acesso a eles. Uma cópia de segurança que contenha apenas o dump da base de dados repõe os seus registos, mas deixa os anexos em falta.
A documentação do Odoo.sh descreve as suas cópias de segurança como incluindo o dump da base de dados, o filestore (anexos e campos binários), os registos e as sessões. É uma referência útil sobre o aspeto de uma cópia de segurança completa em qualquer tipo de alojamento.
- Dump da base de dados: todos os registos, configuração, utilizadores, lançamentos contabilísticos e definições.
- Filestore: anexos e campos binários, como faturas de fornecedores digitalizadas, imagens de artigos e PDFs assinados.
- Código personalizado: no Odoo.sh e no on-premise, os seus módulos personalizados residem no seu repositório de código, que precisa da sua própria proteção.
- Configuração: no on-premise, o ficheiro de configuração do Odoo e a configuração do servidor também devem ser documentados e guardados em segurança.
Quando verificar uma cópia de segurança, confirme sempre que estão presentes tanto o dump como o filestore. A falta do filestore é uma das razões mais comuns para uma base de dados reposta parecer correta à primeira vista e depois apresentar imagens partidas e documentos em falta.
Cópias de segurança por tipo de alojamento
A responsabilidade pelas cópias de segurança depende do local onde a sua base de dados é executada. O Odoo Online e o Odoo.sh são alojados pelo Odoo e incluem cópias de segurança automáticas, enquanto um servidor on-premise torna a sua própria equipa totalmente responsável. A edição Community é normalmente alojada internamente, pelo que se lhe aplicam as responsabilidades do on-premise descritas abaixo.
Odoo Online: o gestor de bases de dados
No Odoo Online, a documentação oficial indica que as bases de dados têm cópia de segurança diária, de acordo com o SLA do Odoo Cloud Hosting. Não precisa de agendar nada para que as cópias de segurança da plataforma aconteçam.
O gestor de bases de dados, a que acede iniciando sessão como administrador da base de dados, oferece uma opção Gerir com as principais ações de que precisa para trabalho de cópias de segurança e testes.
- Descarregar Cópia de Segurança gera um ficheiro ZIP da base de dados que pode guardar no seu próprio arquivo.
- Se Descarregar Cópia de Segurança estiver desativado, a base de dados é demasiado grande para o gestor e deve contactar o Suporte do Odoo para obter outro método de descarga.
- Duplicar cria uma cópia da base de dados; a opção Para fins de teste está ativada por predefinição e desativa ações externas, como emails, pagamentos e ordens de entrega.
- Eliminar remove a base de dados de imediato para todos os utilizadores e não pode ser anulado, por isso descarregue primeiro uma cópia de segurança.
Segundo a documentação, os duplicados no Odoo Online expiram ao fim de 15 dias e cada base de dados pode ter até cinco duplicados. Trate os duplicados como ambientes de teste de curta duração e não como uma estratégia de cópias de segurança.
Odoo.sh: cópias de segurança automáticas e manuais
No Odoo.sh, a base de dados de produção tem cópia de segurança automática todos os dias. A documentação indica que são mantidas sete cópias diárias, quatro semanais e três mensais, sendo as cópias mensais guardadas em servidores de cópias de segurança dedicados. Repor ou descarregar essas cópias mensais exige contactar o Suporte do Odoo.
Os ramos de staging e de desenvolvimento não têm cópia de segurança automática. Podem ser feitas cópias de segurança manuais de produção e de staging para captar um momento específico, por exemplo antes de uma alteração de configuração arriscada. Ficam disponíveis durante três dias, e a documentação refere um limite de cinco cópias de segurança manuais por dia. As bases de dados de desenvolvimento não podem ter cópias de segurança manuais.
O Odoo.sh cria também uma cópia de segurança automática, assinalada como cópia de Update, quando um commit integrado altera as versões dos módulos ou as dependências Python associadas. Se uma integração não as alterar, não é gerada nenhuma cópia, por isso faça uma cópia de segurança manual antes de alterações significativas em produção.
- Use o separador Backups do ramo de produção para rever, descarregar ou repor cópias de segurança.
- Reponha uma cópia de segurança de produção num ramo de staging quando quiser testar com dados reais.
- Use a funcionalidade Import Database para trazer arquivos do gestor de bases de dados padrão, do gestor de bases de dados do Odoo Online, do separador Backups ou da opção Download DB dump de uma build.
On-premise: a sua equipa é responsável por tudo
No seu próprio servidor, nada tem cópia de segurança a menos que a configure. As orientações oficiais de implementação são diretas: configure cópias de segurança diárias das suas bases de dados e dos dados do filestore e copie-as para um servidor de arquivo remoto que não esteja acessível a partir do próprio servidor.
As mesmas orientações avisam que o gestor de bases de dados web é uma ferramenta de desenvolvimento e demonstração e não foi concebido para uso em produção. Recomenda-se vivamente desativá-lo em qualquer sistema exposto à internet, e as operações de produção, como as cópias de segurança automatizadas, devem ser tratadas pelo administrador de sistemas.
- Proteja os ecrãs de gestão de bases de dados com uma palavra-passe mestra forte, gerada aleatoriamente e definida no ficheiro de configuração, nunca com o valor predefinido.
- Desative a listagem de bases de dados nos servidores expostos à internet e use um filtro de bases de dados para que cada nome de anfitrião corresponda à base de dados certa.
- Execute o utilizador PostgreSQL do Odoo sem direitos de superutilizador, como exige a documentação de implementação.
- Faça a cópia de segurança da base de dados e do filestore em conjunto, para que se mantenham coerentes entre si.
Antes de alterações importantes, como passar do Community para o Enterprise, a documentação oficial indica como primeiro passo fazer a cópia de segurança da base de dados Community. Aplique o mesmo hábito antes de qualquer atualização, instalação de módulo ou importação de dados.
Duplicar bases de dados em segurança: a neutralização
Testar numa cópia da produção é a forma mais segura de experimentar novos fluxos de trabalho, importações ou atualizações, mas uma cópia descuidada pode enviar emails reais a clientes ou desencadear pagamentos reais. O Odoo resolve isto com bases de dados neutralizadas, que a documentação define como bases de dados que não são de produção e nas quais vários parâmetros são desativados.
As bases de dados de teste são sempre neutralizadas, incluindo cópias de segurança repostas, duplicados e as bases de dados de staging e de desenvolvimento do Odoo.sh. A lista do que é desativado na documentação não é, expressamente, exaustiva, e inclui o seguinte.
- Ações agendadas, como a faturação automática de subscrições e os envios de email em massa.
- Emails de saída, que no staging do Odoo.sh são intercetados por um mail catcher em vez de serem enviados.
- Sincronização bancária, fornecedores de pagamento e métodos de entrega.
- Tokens IAP e a visibilidade do website para os motores de pesquisa.
Uma faixa vermelha no topo do ecrã assinala uma base de dados neutralizada, para que os utilizadores vejam imediatamente que não estão em produção. Forme a sua equipa para verificar essa faixa antes de introduzir o que quer que seja, e nunca retire a neutralização de uma cópia sem compreender totalmente as consequências.
Retenção, cópias externas, RPO e RTO
As cópias de segurança da plataforma são uma rede de segurança sólida, mas uma boa política mantém também cópias independentes sob o seu controlo. Nas bases de dados alojadas, descarregue periodicamente uma cópia de segurança completa e guarde-a num local separado e com acesso controlado. Nos servidores on-premise, as cópias externas são essenciais e não opcionais.
Duas medidas simples ajudam a decidir quanta proteção precisa. O Recovery Point Objective, ou RPO, é a quantidade de dados recentes que pode dar-se ao luxo de perder; uma cópia de segurança diária implica que pode perder até um dia de trabalho. O Recovery Time Objective, ou RTO, é o tempo durante o qual a empresa consegue funcionar sem o sistema enquanto este é reposto.
Acorde estes objetivos com a administração e depois verifique se a sua configuração atual os cumpre. Se perder um dia inteiro de encomendas de venda for inaceitável, as cópias de segurança diárias não bastam, e deve discutir snapshots mais frequentes ou outras medidas com o seu fornecedor de alojamento ou com a equipa de TI.
Testes de reposição e uma lista de verificação prática
Uma cópia de segurança só está comprovada depois de ter sido reposta. Agende um teste de reposição com uma periodicidade regular, reponha num ambiente de teste neutralizado e confirme que os utilizadores conseguem iniciar sessão, que os registos recentes estão presentes e que os anexos abrem corretamente. Cronometre o processo para conhecer o seu RTO real.
- Confirme o tipo de alojamento que usa e quem é responsável pelas cópias de segurança.
- Verifique se as cópias de segurança incluem tanto o dump da base de dados como o filestore.
- Mantenha uma cópia independente descarregada num local separado e protegido.
- Faça uma cópia de segurança manual antes de atualizações, importações grandes ou alterações de configuração importantes.
- Use duplicados neutralizados ou ramos de staging para todos os testes.
- Reponha regularmente uma cópia de segurança num ambiente de teste e registe os resultados.
- Documente os seus objetivos de RPO e RTO e reveja-os todos os anos.
- No on-premise, desative o gestor de bases de dados público e proteja a palavra-passe mestra.
Como a 1CBMS pode ajudar
A 1CBMS desenha e revê rotinas de cópias de segurança e recuperação para projetos Odoo 19 no Egito e no Iraque, no Odoo Online, no Odoo.sh e em servidores on-premise. Podemos auditar a sua configuração atual, definir com a sua administração objetivos realistas de RPO e RTO, configurar ambientes de teste neutralizados e realizar com a sua equipa um teste de reposição documentado, para que a recuperação seja um procedimento ensaiado e não uma emergência.