Existem alguns erros muito comuns na criação de uma rotina de backup Vamos ver alguns deles.
1 – Caminho incompleto #
O erro mais comum que impede a execução do backup é definir apenas o caminho da pasta, sem especificar os arquivos a serem copiados. É essencial informar quais arquivos dentro da pasta devem ser incluídos na cópia. Para essa especificação, utiliza-se a simbologia do asterisco (*), que indica qual ou quais arquivos se deseja copiar.
Exemplos
- Errado: C:/sistema/database/
- Correto: C:/sistema/database/*.FDB
Formatos
- Para copiar todos os arquivos de dentro da pasta use *.*
- Para copiar Apenas os arquivos com extensão backup *.backup
- Para copiar Apenas os arquivos com extensão FDB *.FDB
2 – Duplicidade de conteúdo #
Ao configurar uma rotina de backup, é importante compreender como funciona a retenção de cópias na nuvem para evitar o consumo desnecessário de armazenamento.
Como funciona a retenção
Quando uma rotina é configurada para manter, por exemplo, 7 cópias na nuvem, o sistema preserva automaticamente as últimas sete versões do backup. Em uma execução diária, isso representa aproximadamente uma semana de histórico, permitindo a restauração de versões anteriores sempre que necessário.
Onde ocorre a duplicidade
Em alguns cenários, a pasta utilizada como origem do backup contém não apenas o arquivo mais recente, mas também os backups gerados em dias anteriores. Se a rotina estiver configurada para enviar todos os arquivos dessa pasta, essas versões antigas também serão enviadas para a nuvem.
Como essas mesmas versões já são preservadas pela retenção configurada (7 cópias, no exemplo), ocorre um armazenamento duplicado.
Ou seja, em vez de cada cópia na nuvem armazenar apenas o arquivo de backup mais recente, cada nova execução passa a armazenar todos os arquivos existentes na pasta de origem. Como a maioria desses arquivos já foi enviada em execuções anteriores, o mesmo conteúdo é armazenado repetidas vezes, aumentando significativamente o consumo de espaço sem agregar novas versões de backup.
Sempre que possível, configure a rotina para realizar o backup apenas do arquivo mais recente gerado pela aplicação ou processo de backup.
Dessa forma:
- o histórico continuará sendo mantido pela retenção configurada na nuvem;
- evita-se o envio repetido de versões antigas;
- reduz-se significativamente o consumo de armazenamento;
- mantém-se o mesmo nível de segurança e disponibilidade para restauração.
O ideal, nessas situações, é configurar a rotina de backup para copiar Somente o Arquivo Mais Recente (SAMR). Para ativar essa opção, basta escolher “SIM” na caixa de configuração SAMR.
3 – Tentar de copiar base de dados aberta. #
Em alguns modelos de banco de dados, quando a base de dados está aberta em uso (ou seja, conectada por um sistema ou aplicação), não é possível copiá-la diretamente por alguns motivos técnicos:
A forma correta de copiar ou transferir dados nesses casos é sempre por meio de ferramentas de backup/exportação (como mysqldump, pg_dump, mongodump, ou backups nativos do SQL Server e Oracle, por exemplo), garantindo consistência e integridade. Assim a melhor prática no caso é fazer a cópia par a nuvem do arquivo de backup que já foi gerado pelo sistema em uso.
Possíveis motivos:
- Bloqueio de arquivos:
O sistema de gerenciamento de banco de dados (SGBD) mantém bloqueios nos arquivos para evitar corrupção. Isso impede que outro processo copie ou altere os dados enquanto estão sendo usados. - Consistência dos dados:
Se você copiar uma base aberta, pode acabar levando apenas parte das informações ou registros em estado intermediário. Isso gera inconsistência e risco de perda de dados. - Transações em andamento:
Bancos de dados trabalham com transações (commit/rollback). Durante uma cópia, transações ainda não confirmadas podem ser copiadas de forma incorreta. - Integridade e segurança:
Muitos SGBDs implementam mecanismos de segurança que bloqueiam acesso direto aos arquivos enquanto estão em uso, garantindo que apenas o próprio banco manipule os dados.
Extensões e arquivos principais dos bancos de dados
Cada sistema de banco de dados usa extensões próprias para seus arquivos principais. Eis os mais comuns:
| Banco de Dados | Extensão principal / Arquivos | Observação |
|---|---|---|
| Microsoft Access | .mdb, .accdb | Não pode ser copiado se estiver aberto no Access. |
| SQLite | .sqlite, .db, .sqlite3 | Arquivo único; bloqueado durante uso. |
| MySQL/MariaDB | .ibd, .frm, .myd, .myi | Arquivos internos; cópia só via dump. |
| PostgreSQL | .dat (arquivos internos) | Não acessados diretamente; backup via pg_dump. |
| Oracle Database | .dbf (datafile), .ctl (control file), .log | Arquivos críticos; não podem ser copiados em uso. |
| SQL Server | .mdf (datafile), .ldf (log file) | Bloqueados enquanto o banco está ativo. |
| MongoDB | collection-*.wt, mongod.lock, arquivos de journal | Usam o storage engine WiredTiger; não devem ser copiados diretamente, apenas via mongodump ou snapshots. |
Alternativa Para fazer o backup de banco de dados aberto
Para realizar o backup de um banco de dados que esteja aberto, uma prática possível é criar um script automatizado na rotina de backup, que primeiro interrompa o serviço do banco de dados de forma provisória, garantindo que não haja transações em andamento. Em seguida, o backup pode ser executado com segurança e, logo após, outro script na rotina de backup é acionado para reiniciar o banco e devolvê-lo ao estado normal de operação.
No entanto, é fundamental ressaltar que tais scripts devem ser elaborados e configurados por um profissional especializado no banco de dados em questão, pois qualquer falha pode comprometer a integridade dos dados ou a disponibilidade do sistema.
Exemplo
@echo off
REM Script para parar, copiar e reiniciar SQL Server
REM 1. Parar o serviço
net stop MSSQLSERVER
REM 2. Copiar arquivos de dados
xcopy “C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA*.mdf” “D:\BackupSQL\” /Y
xcopy “C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA*.ldf” “D:\BackupSQL\” /Y
REM 3. Reiniciar o serviço
net start MSSQLSERVER
4 – Contar com uma quantidade de cópias incorreta #
A rotina de backup permite que você defina o número de cópias que deseja manter para cada cliente. Por exemplo, ao configurar 7 cópias, você garante ter sempre uma semana de arquivos disponíveis em caso de emergência.
Um erro comum é configurar dois ou mais horários de execução na mesma rotina.
Existem três configurações de horários possíveis para a rotina de backup:
- 5 minutos após o computador ser ligado.
- Diariamente em um horário específico.
- Em dias específicos e horários determinados.
O problema de usar múltiplas configurações de horário na mesma rotina reside no fato de que isso reduz a quantidade de dias com cópias armazenadas.
Exemplo: Se você deseja manter 7 cópias, mas configura a execução para:
- 5 minutos após ligar;
- Diariamente às 15:00;
- Todos os dias individualmente às 12:00.
Na prática, você estará fazendo 3 cópias por dia. Com isso, as 7 cópias se esgotarão em pouco mais de 2 dias (2 dias completos mais uma cópia), diminuindo drasticamente o seu alcance no tempo de backups úteis.
5 – Não informar que deseja copiar sub pastas #
Outro erro muito comum é não indicar que se deseja copiar o conteúdo das subpastas quando a pasta principal não contém arquivos. Em certas situações, o arquivo a ser copiado está em uma subpasta, ou há vários arquivos em múltiplas subpastas, e a pasta principal está, na verdade, vazia. Nesses casos, é fundamental que a opção SUBPASTAS seja configurada como SIM.
6 – Não acompanhar as métricas de backup #
Não acompanhar as métricas de utilização do backup não caracteriza um erro de configuração. No entanto, a ausência desse acompanhamento pode fazer com que o ambiente evolua de forma diferente do planejado, sem que isso seja percebido.
Com o tempo, alterações nas rotinas, inclusão de novos diretórios, crescimento do volume de dados ou mudanças na forma como os backups são gerados podem aumentar gradativamente o consumo de armazenamento.
Sem o monitoramento periódico das métricas, é possível que as rotinas passem a utilizar mais espaço do que o previsto no planejamento inicial, resultando em consumo acima da franquia contratada ou na necessidade de revisar a estratégia de backup.
Por esse motivo, recomenda-se acompanhar regularmente as métricas de armazenamento e revisar as rotinas sempre que houver alterações no ambiente. Essa prática permite identificar desvios de consumo antecipadamente e realizar ajustes antes que eles impactem a operação ou gerem custos adicionais.
Você pode acompanhar visualmente excessos em MÉTRICAS DE BACKUP. Clique AQUI para ver o artigo que explica a funcionalidade
Consulte AQUI os tipos e a lista completa de alertas.
Gostou do artigo? Veja então as novidades em nosso SITE, compartilhe o artigo com seus amigos e siga a Master Remote no LinkedIn, Youtube, Instagram e Facebook. Além disso, aproveite para explorar outros artigos ao lado e fique por dentro das últimas novidades sobre tecnologia para atendimento ao cliente e cibersegurança.
VOCÊ PODE AINDA SE INTERESSAR POR:
