Qual método de backup mantém um contentor de base de dados em execução consistente num NAS doméstico?

Para a maioria dos utilizadores de NAS domésticos e servidores auto-hospedados, o padrão mais seguro é um backup lógico nativo da base de dados criado enquanto a base de dados está em execução, seguido de um backup normal desse dump juntamente com a configuração do contentor e os ficheiros da aplicação. Use uma cópia com o contentor parado por pouco tempo quando o tempo de inatividade for aceitável, e use um snapshot coordenado do sistema de ficheiros apenas quando a base de dados estiver descarregada, bloqueada, com checkpoint ou preparada de outra forma para o snapshot. Uma cópia simples de um volume de base de dados ativo não é um método de backup consistente.

Defina “Consistente” como uma Restauração que a Base de Dados Aceita

Um backup consistente não é apenas uma árvore de pastas completa. Após a restauração, o motor da base de dados deve iniciar, recuperar transações corretamente, passar verificações de integridade e apresentar um estado pontual que a aplicação possa usar. Num servidor doméstico a correr Immich, Nextcloud, Paperless-ngx, Home Assistant ou outra aplicação auto-hospedada, isso significa que a base de dados, os uploads, a configuração e os segredos devem estar em concordância.

A persistência do contentor explica apenas onde os ficheiros vivem. Não torna uma base de dados em execução segura para copiar. Uma base de dados pode ter transações ativas, páginas em cache, logs de escrita antecipada, ficheiros temporários ou metadados que mudam enquanto o software de backup do NAS lê o volume.

Método 1: Use um Dump Lógico Nativo da Base de Dados como Padrão do NAS Doméstico

Um dump lógico pede ao motor da base de dados para exportar uma representação consistente dos esquemas e registos. Para um contentor PostgreSQL ou MariaDB modesto num NAS familiar, este é geralmente o método mais fácil para agendar, inspecionar, copiar para fora do local e restaurar num contentor de substituição limpo. Um guia atual de backup Docker demonstra este padrão executando dumps nativos da base de dados a partir de um contentor de backup agendado.

Escreva o dump para um diretório de backup dedicado fora do volume de dados ativo. Depois, deixe o trabalho de backup do NAS proteger o dump, o ficheiro Compose, o modelo de ambiente, a configuração da aplicação e os dados carregados. Não exponha palavras-passe de produção no nome do ficheiro do dump ou em registos não protegidos.

Método 2: Pare brevemente a base de dados antes de copiar o seu volume

Uma cópia de contentor parado é simples e fisicamente completa. Pare primeiro os escritores da aplicação, pare a base de dados de forma limpa, confirme que o processo terminou, copie todo o volume persistente ou diretório da base de dados montado por ligação, e depois reinicie a stack. Um guia Docker e MariaDB descreve cópias de volumes físicos como rápidas mas dependentes da versão e normalmente associadas a tempo de inatividade.

Este método funciona bem para um pequeno NAS doméstico onde alguns minutos de manutenção são aceitáveis e a restauração usará uma versão compatível da base de dados. É menos portátil do que um dump lógico e pode prolongar o tempo de inatividade quando o volume é grande. Mantenha a tag da imagem da base de dados e o layout de armazenamento com o backup para não restaurar ficheiros físicos numa versão de motor incompatível.

Método 3: Coordene um Snapshot Rápido com a Base de Dados

Os sistemas de snapshot ZFS, Btrfs, LVM e NAS podem capturar rapidamente um volume grande de base de dados, mas o snapshot deve ser coordenado com a base de dados. Para MariaDB ou MySQL, isso pode significar uma janela curta de bloqueio ou flush; para PostgreSQL, pode significar o processo de backup ou checkpoint suportado pela base de dados; para uma base de dados gerida pela aplicação, pode significar um hook pré-snapshot.

Uma discussão sobre snapshots de base de dados explica que uma cópia ao vivo no disco pode ser internamente inconsistente a menos que a base de dados esteja congelada ou o snapshot seja feito de forma atómica. O intervalo de bloqueio ou quiescência deve ser curto: preparar a base de dados, criar o snapshot, libertar as escritas e copiar o snapshot depois.

Este método é útil quando a base de dados é demasiado grande para dumps lógicos frequentes ou quando necessita de um intervalo de ponto de recuperação mais baixo. Requer uma scriptagem e testes de restauração mais cuidadosos do que um fluxo de trabalho básico de dump para servidor doméstico.

Não trate a imagem Docker ou a exportação do contentor como backup da base de dados

A imagem do contentor contém o runtime da aplicação, não necessariamente os dados persistentes em tempo real. Exportar ou fazer commit do contentor pode omitir volumes nomeados e não solicita à base de dados que crie um ponto de recuperação consistente. Uma conta de backup de contentor PostgreSQL conclui que o Docker save e commit não substituem as técnicas de backup específicas do PostgreSQL.

Para um servidor doméstico ZimaOS ou Docker, mantenha a definição de implantação e o plano de proteção de dados separados: preserve os ficheiros Compose e as tags das imagens para que o serviço possa ser reconstruído, e preserve a base de dados através de um método consistente com a base de dados para que o seu estado possa ser restaurado.

Nunca copie diretamente um volume de base de dados que está a ser escrito ativamente

O software de cópia de segurança NAS pode ler diferentes ficheiros de base de dados em momentos diferentes. O arquivo resultante pode conter um ficheiro de dados de um estado de transação, um log de outro e metadados de um terceiro. Uma visão geral dos métodos de cópia de segurança SQL open-source alerta que uma base de dados em movimento pode ser capturada num momento inconsistente enquanto o estado importante ainda está na memória.

A recuperação de falhas pode reparar alguns snapshots capturados atomicamente, mas uma cópia recursiva ordinária de ficheiros não é atómica. Se a aplicação não tolerar tempo de inatividade, use um despejo lógico, uma ferramenta de cópia de segurança física suportada ou um snapshot coordenado.

Trate os Contentores SQLite como Bases de Dados, Não como Ficheiros Ordinários

Muitas aplicações para servidores domésticos usam SQLite porque é compacto e fácil de implementar. O risco é que os administradores vejam um ficheiro .db e assumam que pode ser copiado enquanto a aplicação está a escrever. Em modo WAL, alterações recentes comprometidas podem ainda estar fora do ficheiro principal. Um artigo prático sobre recuperação SQLite recomenda usar o mecanismo de cópia de segurança online ou uma cópia limpa fechada em vez de copiar um ficheiro de base de dados ativo.

Use a cópia de segurança incorporada da aplicação se existir. Caso contrário, use a função de cópia de segurança online do SQLite ou pare a aplicação de forma limpa antes de copiar todo o diretório da base de dados. Não copie apenas o ficheiro principal da base de dados deixando para trás o seu diário ou estado WAL.

Escolha o método pelo tempo de inatividade, tamanho da base de dados e portabilidade do restauro

Faça Backup da Aplicação Self-Hosted Completa, Não Apenas do Banco de Dados

Um pacote de recuperação utilizável deve incluir o backup do banco de dados, ficheiro Docker Compose, versões das imagens, variáveis de ambiente ou um pacote de segredos recuperável, configurações de proxy reverso, configuração da aplicação, ficheiros carregados e quaisquer chaves de encriptação. Fazer backup apenas do despejo SQL pode restaurar registos mas deixar a aplicação incapaz de encontrar fotos, documentos, miniaturas, certificados ou caminhos de armazenamento.

Para planeamento de recuperação de servidor doméstico, o guia ZimaSpace sobre bind mounts e volumes nomeados explica porque os caminhos de armazenamento visíveis ajudam na recuperação mas ainda não substituem um backup de banco de dados consistente com a aplicação.

Comprove o Método Restaurando para um Novo Contentor

Crie uma stack de teste isolada com um novo nome de projeto, portas de host diferentes e um diretório de dados temporário. Restaure o despejo ou snapshot, inicie o banco de dados, execute suas verificações de integridade ou consistência e depois conecte uma cópia de teste da aplicação. Confirme que usuários, registos, anexos e transações recentes estão presentes.

Meça tanto o ponto de recuperação quanto o tempo de recuperação. Se um despejo lógico for consistente mas demorar muito para restaurar, mantenha-o como a camada portátil de recuperação e adicione um snapshot coordenado mais rápido. Se uma cópia do volume parado restaurar rapidamente mas apenas para a mesma versão do banco de dados, mantenha um despejo lógico como fallback de migração.

Perguntas Frequentes

Pausar um contentor de banco de dados é suficiente antes de copiar o volume?

Não como regra geral. Pausar congela o processo mas não prova que o banco de dados descarregou o estado correto para um backup portátil. Use um despejo nativo do banco de dados, um encerramento limpo ou um procedimento documentado de quiescência e snapshot.

Um snapshot de NAS sozinho é suficiente para PostgreSQL ou MariaDB?

Apenas quando o snapshot for atómico e coordenado com o processo de consistência suportado pelo banco de dados. Um snapshot não coordenado pode ser apenas consistente em caso de falha, e uma cópia de ficheiro não atómica pode ser pior.

O que devo fazer backup para uma aplicação de servidor doméstico baseada em SQLite?

Use a exportação da aplicação ou o backup online SQLite quando disponível. Também preserve a configuração da aplicação, o ficheiro Compose, segredos, anexos e o diretório que contém a base de dados em vez de assumir o principal .db o ficheiro é a aplicação completa.

Recomendação Final

Use despejos lógicos agendados como padrão para a maioria dos contentores PostgreSQL e MariaDB num NAS doméstico. Use uma cópia limpa do volume parado quando um tempo de inatividade curto for aceitável, e utilize snapshots coordenados ou ferramentas físicas nativas do banco de dados quando o banco for grande ou a janela de ponto de recuperação for apertada. Seja qual for o método escolhido, restaure-o num novo contentor antes de confiar nele.