Existe algum software de backup gráfico que não seja propenso a problemas de consistência?

Question

Como por esta resposta para a pergunta " Posso continuar trabalhando quando o backup estiver em andamento? ," o software de backup padrão no Ubuntu, Deja Dup, está sujeito a problemas de consistência ao fazer o backup. Ou seja, se o usuário alterar arquivos em um sistema de arquivos gravável enquanto o backup estiver sendo feito, o backup pode não estar em um estado sensato e restaurá-lo integralmente restaurará um sistema corrompido. Mesmo a restauração de arquivos individuais pode restaurar arquivos quebrados.

O conselho para não fazer nenhum trabalho enquanto o backup está sendo feito é uma solução alternativa, mas não é realmente prático. Um usuário que "não está trabalhando" não significa que os arquivos não estejam sendo modificados nos bastidores.

A resposta a que me vinculei diz sobre snapshots:

This can be achieved using LVM or a newer generation filesystem such as BtrFS. This will snapshot the whole volume as if you were taking a picture of it. Changes/writes are still possible, but the backup process is being run from the read-only snapshot taken earlier.

Por exemplo, nos sistemas Windows, a maioria dos softwares de backup é executada em uma "cópia de sombra", um instantâneo semanticamente consistente do sistema de arquivos mantido pelo sistema operacional. O usuário pode continuar trabalhando e outras modificações não farão parte do backup em execução no momento.

No entanto, eu não sei se o Deja Dup no Ubuntu usa qualquer tipo de snapshot se estiver disponível.

A minha pergunta é: existe algum software de backup automatizado para o Ubuntu que:

• é fácil de usar, por meio de uma GUI, adequado para usuários que não querem usar a linha de comando ou escrever seus próprios scripts
• garante a consistência dos backups usando instantâneos ou impingindo somente leitura na origem do backup (pesado, mas perfeitamente válido) ou qualquer outra abordagem para evitar inconsistência?

Answer 1

A menos que você seja uma loja 24 horas por dia, 7 dias por semana, você manda o servidor desconectar todos às duas da manhã e fazer backups por duas horas ou o que for preciso. Normalmente, isso é feito em conjunto com o "Processamento de fim do dia", que acumula registros detalhados nos registros do Arquivo mestre, fecha os finais do mês, os finais do ano, etc.

O problema básico é que alguns arquivos irão "mudar de forma" se alguém estiver adicionando ou excluindo registros. Tomemos, por exemplo, arquivos ISAM (Indexed Sequential Access Method) onde há um arquivo de dados brutos e, em seguida, separe os arquivos Index de cada chave (por exemplo, Número do cliente, Número de telefone, etc.). Se você dissesse primeiro fazer backup do arquivo de chaves para os números do cliente, um usuário adicionou um novo cliente e fez o backup do arquivo de dados brutos, você teria um erro de integridade de dados.

SQL é a escolha popular nos dias de hoje para bancos de dados, caso em que um despejo de SQL é executado sem chaves de backup, eu acho. Learning SQL (pronuncia-se Sea-Quill) está na minha lista de tarefas há mais de 30 anos.

Seja qual for o seu ambiente, você precisa estudar os requisitos de backup com cuidado e testá-los periodicamente, restaurando-os em um banco de dados de teste.

O backup de programas geralmente é excessivo, porque eles podem ser reinstalados. A exceção são seus próprios scripts que você desenvolve.

Para reiterar, os backups mais seguros são aqueles em que todos os usuários são desconectados do sistema. Quando isso não pode ser garantido, deve-se buscar ajuda profissional.