Esta pergunta abrange três níveis distintos, cada um com uma resposta diferente. Uma eliminação feita dentro da aplicação pode ser revertida: nada é realmente apagado; a linha é movida para uma lixeira, de onde pode ser restaurada com um clique. Os seus dados saem sempre que quiser, cada lista tem o seu botão de exportação. Mas a base de dados de uma aplicação implementada NÃO tem qualquer cópia de segurança automática integrada no produto: não existe nenhum comando de cópia de segurança na cadeia de implementação, cabe ao fornecedor de alojamento implementar essa funcionalidade desde o início. Por outras palavras: um clique acidental resolve-se sozinho; uma base de dados perdida não se recupera. Esta página define com precisão onde passa essa fronteira, para que possa formular as perguntas certas antes de introduzir dados reais.
Eliminar, na sua aplicação, não destrói nada
O botão Eliminar não elimina: marca simplesmente a linha como eliminada através de uma coluna dedicada. Ela desaparece então das listas, dos totais e dos indicadores, mas permanece intacta na base de dados. Assim que uma linha é eliminada, surge uma ficha «Lixeira» nas Definições, com um botão «Restaurar». Isto é verificável no código entregue: nenhuma das rotas geradas invoca uma eliminação definitiva na base de dados.
A isto junta-se uma confirmação em dois passos, um primeiro clique prepara a eliminação, um segundo confirma-a, em vez da caixa de diálogo de confirmação do navegador. O caso mais frequente por larga margem, o clique acidental no final do dia, resolve-se assim em trinta segundos e sem necessidade de contactar ninguém. É também a única das três camadas totalmente gerida pela aplicação, razão pela qual surge em primeiro lugar.
Obter os seus dados sempre que quiser
Cada lista inclui um botão de exportação em formato CSV. Este exporta apenas as linhas que VOCÊ VÊ, filtradas pela pesquisa e pelos filtros ativos, e o rótulo do botão indica o número exato de linhas a exportar: nunca são exportados dados que não estão visíveis no ecrã. O ficheiro é gerado para abrir corretamente numa folha de cálculo em português, sem a linha de caracteres com acentos corrompidos que habitualmente afeta as exportações.
Trata-se de uma cópia que fica sob o seu controlo, e deve ser designada pelo que realmente é: não é uma cópia de segurança no sentido técnico. Um ficheiro CSV não restaura uma aplicação, não contém nem as ligações entre as suas tabelas, nem o histórico, nem os registos eliminados. Serve para recuperar o controlo: abrir os seus dados numa folha de cálculo, enviá-los ao seu contabilista ou alimentar outra ferramenta. É o que evita que fique preso num sistema, não o que o protege contra uma falha.
O que NÃO é feito, e o que deve decidir
Quando a sua aplicação é implementada, recebe uma base de dados PostgreSQL própria. Contudo, nada na cadeia de implementação efetua cópias de segurança dessa base: não existe qualquer comando de cópia de segurança no código que implementa as aplicações. Isto não é um esquecimento dissimulado, mas sim uma fronteira clara, a responsabilidade pelas cópias de segurança depende do local onde a aplicação está a ser executada, cabendo, por isso, ao seu fornecedor de alojamento (seja você, o seu prestador de serviços ou nós, quando fazemos o alojamento).
Três perguntas bastam para clarificar esta questão, e devem ser formuladas antes de introduzir quaisquer dados reais. Quem produz a cópia, e com que frequência? Onde é guardada, noutro local que não a máquina que executa a aplicação, pois, caso contrário, uma única falha levaria ambos? E, sobretudo: alguém já RESTAUROU alguma vez a partir dessa cópia? É esta terceira pergunta que normalmente se esquece, e é também a única que prova algo concreto: uma cópia de segurança nunca testada não é uma cópia de segurança, é apenas uma suposição.
O que muda conforme o tipo de dados que lá colocar
Nem todos os conteúdos exigem o mesmo nível de proteção. Para uma ferramenta cujo conteúdo pode ser reconstruído, um planeamento semanal, um acompanhamento leve que se reinsere em cerca de uma hora, uma exportação mensal arquivada em algum local é mais do que suficiente. Já para um registo que NÃO pode ser reconstruído, os seus associados, o histórico das suas intervenções, os processos em curso, a cópia de segurança automatizada da base de dados é um requisito prévio, não uma opção: ninguém reescreve três anos de histórico de memória.
A boa notícia é que não há obstáculos técnicos: o código gerado é Next.js e Prisma padrão sobre uma base de dados PostgreSQL, sem formatos proprietários a contornar, e fazer cópias de segurança de uma base PostgreSQL é uma operação que qualquer prestador de serviços sabe executar. A pergunta, portanto, nunca é «é possível?», mas sim «quem o faz, desde quando e já foi verificado pelo menos uma vez?».