Depois de o volume da base de dados do Jellyfin ficar cheio, interrompa as novas gravações, preserve a base de dados e os ficheiros WAL, liberte espaço em segurança e valide a base de dados antes de reiniciar as tarefas normais.
O Jellyfin não inicia, apresenta erros do SQLite ou abre sem utilizadores depois de o volume ter ficado sem espaço livre? Não elimine imediatamente ficheiros da base de dados nem execute tarefas de limpeza. Registe primeiro o volume, os bytes livres, os nomes dos ficheiros da base de dados, o estado do contentor e a cópia de segurança mais recente que se sabe estar correta.
Impeça que a falha se transforme numa tempestade de gravações
Pare o Jellyfin e qualquer importador, analisador ou serviço secundário que escreva no mesmo volume. Confirme qual é o ponto de montagem cheio, incluindo os inodes, e preserve a base de dados principal, bem como quaisquer ficheiros complementares `-wal` ou `-shm`. Um disco cheio pode deixar ficheiros de configuração vazios ou parcialmente gravados; um incidente específico de uma versão mostra que libertar espaço, por si só, pode não restaurar o arranque (caso de recuperação após volume cheio).
Liberte espaço de registos descartáveis, ficheiros de transcodificação concluídos ou caches que se saiba ser possível reconstruir, mas apenas depois de copiar o estado persistente. Nunca remova a base de dados como primeiro passo.
Registe o tamanho da base de dados, os ficheiros WAL, os registos, a cache e o espaço livre restante antes da limpeza. Isto permite identificar se o volume ficou cheio devido ao crescimento da base de dados, à saída da transcodificação, aos registos ou a outro contentor.
Verifique a integridade da base de dados antes de tentar repará-la
Trabalhe numa cópia da base de dados enquanto o Jellyfin permanece parado. Execute uma verificação de integridade com as ferramentas SQLite disponíveis no seu ambiente e analise os registos à procura de erros como “disk full”, imagem malformada ou impossibilidade de abrir. Se a verificação for bem-sucedida, liberte espaço, reinicie uma vez e confirme os utilizadores, as bibliotecas e a reprodução.
Se a base de dados estiver malformada, restaure primeiro a cópia de segurança mais recente que se sabe estar correta. Um fluxo de recuperação controlado pode utilizar ferramentas de recuperação do SQLite numa cópia, mas isso não substitui uma cópia de segurança validada e não deve ser feito numa base de dados ativa (procedimento de recuperação baseado numa cópia).
Depois de libertar apenas dados que possam ser reconstruídos, confirme que os ficheiros da base de dados permanecem juntos e legíveis. Um reinício antes desta verificação pode transformar uma gravação incompleta numa segunda falha.
Impeça que o volume volte a atingir o mesmo limite
Mova a cache e a saída da transcodificação para um caminho monitorizado, configure alertas acima do limiar mínimo de espaço livre e reveja a retenção de registos e os agendamentos de análise. Mantenha o estado da aplicação separado dos conteúdos multimédia em massa, para que uma biblioteca em crescimento não possa consumir o volume da base de dados.
Reinicie duas vezes, execute a análise ou reprodução original e confirme que a cópia de segurança seguinte é concluída. Escale o problema quando as verificações de integridade falharem, a base de dados não puder ser restaurada ou o volume voltar a ficar cheio sem um processo que esteja visivelmente a escrever.
Se a verificação de integridade for bem-sucedida, reinicie uma vez e execute a carga de trabalho original dos utilizadores e das bibliotecas. Se falhar, trabalhe a partir de uma cópia ou restaure a base de dados, em vez de a abrir repetidamente enquanto está danificada.
Comprove a recuperação e evite que o volume volte a ficar cheio
Faça um reinício a frio, execute uma análise, uma sessão de reprodução e uma cópia de segurança depois da reparação. Confirme que o volume da base de dados mantém uma margem de espaço livre monitorizada enquanto a carga de trabalho está ativa.
Conserve a reparação quando os utilizadores, as bibliotecas, as tarefas agendadas e a reprodução forem todos restaurados. Adicione alertas para o espaço e os inodes e mova a cache ou os registos para uma função que não possa consumir o volume da base de dados.
Escale o problema quando o volume voltar a ficar cheio sem um processo que esteja visivelmente a escrever, as verificações de integridade falharem ou a base de dados restaurada perder utilizadores ou estado.
Suporte e Dicas
Mais para Ler

Como otimizar as ligações à base de dados do Jellyfin para contentores simultâneos
Comece com um único proprietário da base de dados e um comportamento de bloqueio do SQLite devidamente avaliado; adicione outro backend apenas quando a...

Como evitar tarefas ou importações duplicadas no Jellyfin
O trabalho duplicado geralmente resulta de agendadores sobrepostos ou de mais do que um processo de escrita; atribua um responsável, um caminho e uma...

Porque é que o Jellyfin recria ficheiros em falta com o proprietário errado?
A propriedade incorreta deve-se normalmente a uma incompatibilidade de identidade ou a um caminho de importação diferente; confirme o utilizador ativo do contentor antes...

