Repository Restic bloccato dopo un arresto anomalo: cause, controlli e soluzioni

Un repository Restic può rimanere bloccato perché un altro processo è ancora attivo, un arresto anomalo ha lasciato uno stato obsoleto, il backend ha ritardato gli aggiornamenti oppure un’attività di manutenzione mantiene un blocco esclusivo.

Su un home server con più host, è pericoloso presumere che l’ultimo arresto anomalo visibile abbia creato l’unico blocco. Un’attività di pruning potrebbe essere ancora in esecuzione altrove, un container potrebbe essersi riavviato con la stessa pianificazione oppure lo storage a oggetti potrebbe non mostrare immediatamente lo stato più recente. Inizia sospendendo le nuove pianificazioni e leggendo l’identità del blocco; rimuovi un blocco solo dopo che host, processo, orario e attività del repository indicano tutti che l’operazione è terminata.

Leggi l’identità del blocco prima di intervenire

Sospendi le nuove pianificazioni di backup, forget, check e prune su ogni macchina che può raggiungere il repository. Elenca i blocchi e salva host, ID del processo, utente, ora di creazione, ora di aggiornamento e ruolo esclusivo o non esclusivo. Poi controlla il processo corrispondente e i log del servizio sull’host indicato, invece di basarti soltanto sull’età del blocco.

I blocchi obsoleti seguono spesso un processo Restic interrotto, ma una pipeline interrotta è solo una delle possibili cause. Un processo che riceve un segnale non gestito correttamente può lasciare uno stato simile a quello di un’attività remota ancora in esecuzione.

Se il PID è attivo e i log avanzano, attendi oppure arresta l’attività tramite il relativo gestore dei servizi; non rimuovere il blocco mentre il processo è in esecuzione. Se il processo è assente e l’host non ha riavviato la stessa attività, il blocco diventa un candidato obsoleto. Se l’host non è raggiungibile o la visualizzazione del backend è incoerente, lo stato resta non verificato e non è giustificata alcuna azione distruttiva.

Distingui le quattro firme dei blocchi

Un processo di scrittura attivo presenta un processo corrispondente, attività recente nei log e un blocco che viene aggiornato. Un’uscita non corretta non presenta processi attivi e mostra un timestamp del blocco fisso dopo l’arresto dell’host o del container. Un ritardo del backend si manifesta quando i client non concordano sull’elenco dei blocchi o quando i timestamp sono in ritardo rispetto all’attività nota del repository. Una manutenzione incompleta mostra un blocco esclusivo e un log di check o prune ancora in evoluzione.

Un ampio ordine di risoluzione dei problemi di Restic mantiene separati i blocchi del repository, gli errori di prune e la possibile corruzione, così da non applicare una correzione per un blocco obsoleto a un problema di storage.

Verifica una firma alla volta. Conferma prima che il processo sia attivo, poi confronta timestamp e log, quindi controlla la raggiungibilità e l’orologio del backend e infine esamina la manutenzione. Se due firme restano plausibili, mantieni il blocco e analizza il ramo più sicuro; rimuovere il blocco non è un test diagnostico, perché modifica la protezione che stai cercando di comprendere.

Rimuovi solo un blocco dimostrato come obsoleto

Prima di rimuovere il blocco, controlla ancora una volta ogni client, controller di automazione, host dei container, e servizio sul lato repository. Salva l’elenco attuale dei blocchi e i log recenti. Usa il normale comando di rimozione dei blocchi obsoleti, non un’opzione di rimozione totale o senza blocchi, perché il percorso standard è progettato per lasciare intatti i blocchi attivi.

Un vero errore dovuto a un blocco obsoleto può interrompere una pianificazione di backup altrimenti stabile, ma l’età di un singolo caso non definisce una soglia universale sicura per la cancellazione.

Se il comando standard rimuove il record obsoleto e non compare subito un nuovo blocco, procedi con un elenco del repository in sola lettura. Se rifiuta l’operazione perché il blocco è attivo, fermati e individua il proprietario. Se compare immediatamente un nuovo blocco, una pianificazione o un container riavviato è ancora in esecuzione; disabilita quella fonte prima di tentare un’altra riparazione.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Ripeti l’operazione originale e verifica che il problema non si ripresenti

Esegui la stessa operazione che aveva avuto esito negativo, registrando avanzamento e codice di uscita. Osserva la comparsa del blocco, il suo aggiornamento mentre l’attività è attiva e la sua scomparsa dopo un’uscita corretta. Poi lascia eseguire un normale ciclo pianificato. In questo modo riproduci il fattore scatenante originale e ottieni una conferma più significativa rispetto a un semplice elenco riuscito del repository.

Se il repository diventa di sola lettura o la manutenzione non riesce dopo la rimozione del blocco, segui il percorso separato di ripristino dopo un prune interrotto invece di rimuovere ripetutamente i blocchi.

Il ripristino è riuscito quando si completano due cicli con il carico originale, ogni blocco viene aggiornato mentre l’attività è attiva e rimosso all’uscita, e un controllo del repository o un ripristino di esempio funziona normalmente. Esamina il problema più a fondo se i blocchi ricompaiono dopo uscite corrette, i client non concordano sullo stato del backend oppure il controllo segnala oggetti del repository mancanti o danneggiati. Mantieni attivo il blocco per tutta la durata dell’indagine.