Se icewhale-files-backup arriva a utilizzare diversi gigabyte di RAM e attiva ripetutamente l'OOM killer su ZimaOS 1.7.0, aggiorna prima a ZimaOS 1.7.1 o versione successiva. Le note di rilascio di IceWhale per la versione 1.7.1 indicano esplicitamente la correzione dell'uso anomalo della memoria in determinati scenari di operazioni sui file e dei problemi di errore o interruzione dei backup.
La discussione originale documentava una grave regressione della versione 1.7.0: la memoria passava da circa 3,5 GB a oltre 10 GB, il kernel terminava Backup, Restart=always lo riavviava e il ciclo destabilizzava il server. Il mascheramento del servizio interrompeva il ciclo, ma era solo una soluzione di emergenza.
Riconoscere il ciclo OOM
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hSe il processo Backup torna ripetutamente a essere quello con il maggiore consumo di memoria, il ciclo di riavvio può privare Docker e gli altri servizi delle risorse necessarie.
Aggiornare alla versione 1.7.1 o successiva
Le note di rilascio ufficiali di ZimaOS 1.7.1 elencano correzioni per l'uso anomalo della memoria e per le attività di backup che potevano non riuscire o venire interrotte.
Ripristino di emergenza su 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceIl mascheramento era necessario perché il normale arresto o la disabilitazione non impedivano sempre il riavvio del servizio in base alla relativa politica di riavvio.
Comprendere cosa interrompe il mascheramento
Il mascheramento disabilita la funzione Backup integrata. Usalo solo per stabilizzare un host inutilizzabile abbastanza a lungo da poterlo aggiornare o recuperare i dati.
Rimuovere il mascheramento dopo l'aggiornamento
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceQuindi esegui un piccolo backup controllato monitorando la RAM e lo swap.
I carichi di lavoro dei backup USB erano un fattore scatenante comune
Più utenti hanno segnalato comportamenti simili con destinazioni di backup USB. Questo aiuta a riprodurre il bug, ma non dimostra che sia stato il contenitore stesso a causarlo.
Verificare la completezza del backup
Confronta il numero di file nella sorgente e nella destinazione ed esegui un test di ripristino. La guida alla verifica dei backup aiuta a ridurre la dipendenza da una singola attività.
Verificare se Docker è stato danneggiato dall'esaurimento della memoria
Nella discussione, la pressione prolungata sulla memoria ha reso infine non disponibili le applicazioni Docker. Dopo aver stabilizzato l'host, verifica docker ps, il demone Docker e i container critici prima di riavviare un carico di lavoro di backup di grandi dimensioni.
Iniziare con un piccolo backup dopo l'aggiornamento
Non eseguire immediatamente di nuovo l'attività da più terabyte o il processo USB che ha causato l'errore. Crea una piccola attività di test, monitora la memoria per 10–20 minuti, quindi aumenta gradualmente il numero di file e le dimensioni totali. In questo modo sarà più facile verificare se il servizio corretto mantiene il consumo entro limiti ragionevoli.
Il numero di file conta quanto i byte
Centinaia di migliaia di file piccoli possono richiedere molto più lavoro sui metadati rispetto a pochi file multimediali di grandi dimensioni. Quando invii una segnalazione all'assistenza, includi sia i byte totali sia il numero approssimativo di file.
Mantenere un percorso di backup indipendente durante i test
Se la funzione Backup integrata era precedentemente incompleta o instabile, mantieni un'altra copia verificata con uno strumento o una destinazione separata finché un test di ripristino non conferma l'affidabilità dell'attività ZimaOS corrente.
Conservare i log precedenti e successivi alla correzione
Salva i messaggi OOM, i processi con il maggiore consumo di memoria, la versione di ZimaOS e il tipo di destinazione del backup prima dell'aggiornamento. Quindi ripeti lo stesso carico di lavoro controllato dopo la versione 1.7.1 o successiva e confronta la crescita della memoria. In questo modo avrai la prova che la regressione è stata risolta, invece di basarti soltanto sul fatto che “il server sembra stabile”.
Se la memoria continua a crescere senza limiti nella versione corretta, interrompi l'attività e invia all'assistenza le misurazioni precedenti e successive.
Domande frequenti
La perdita di memoria è stata confermata da più utenti?
Sì. Diversi utenti hanno segnalato lo stesso comportamento nella versione 1.7.0.
La versione 1.7.1 ha risolto questo tipo di problema?
Sì. Il changelog ufficiale include correzioni relative alla memoria e ai backup che lo riguardano direttamente.
Devo tornare alla versione 1.6.2?
Era una soluzione temporanea precedente alla versione 1.7.1. Gli utenti attuali dovrebbero preferire la versione stabile corretta.
Come posso sapere se la correzione ha funzionato?
Esegui un backup controllato monitorando memoria, swap, log e completezza della destinazione.
