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 – Tentar de copiar base de dados aberta. #
É 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), 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
3 – 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.
4 – Não informar que deseja copiar sob 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.
5 – Estourar Limite de backup #
Muitas vezes, o excesso da cota de backup ocorre porque o usuário, em sua rotina, copia novamente todos os arquivos de uma pasta específica, mesmo já existindo versões anteriores salvas. Esse hábito gera duplicação desnecessária e consome espaço rapidamente.
Na prática, seria suficiente copiar apenas o arquivo mais recente, visto que os anteriores já estão preservados em backups passados.
Essa atenção no processo evita o desperdício de espaço, otimiza a eficiência do armazenamento e assegura que o backup cumpra seu papel sem exceder os limites de cota.
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.

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: