Come rimuovere un blocco Restic obsoleto senza interrompere un backup attivo

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Clear a Stale Restic Lock Without Interrupting an Active Backup - Zima Store Online

Un lock Restic obsoleto deve essere eliminato solo dopo aver dimostrato che ogni host e processo elencato è inattivo. La correzione consiste in un normale sblocco dell'elemento obsoleto, non nella rimozione forzata di tutti i lock.

Quando più home server condividono un repository, un lock apparentemente vecchio potrebbe appartenere a un'attività remota lenta, a un container riavviato o a un processo il cui orologio differisce da quello del computer dell'operatore. Sospendi prima le nuove pianificazioni, salva i metadati del lock, controlla l'host indicato e ogni controller di manutenzione, quindi usa la procedura di pulizia standard. Se non è possibile verificare uno dei proprietari, interrompi la procedura e conserva il lock.

Sospendi i nuovi processi e identifica ogni proprietario del lock

Disabilita i timer, le voci cron, le pianificazioni dei container e i processi di orchestrazione che possono avviare Restic sul repository. Salva l'elenco attuale dei lock e i log recenti dei servizi. Per ogni lock, annota host, ID del processo, utente, timestamp e se è esclusivo, quindi controlla il processo indicato su quell'host preciso.

Un controllo esclusivo del repository può bloccare altre attività e un lock di controllo interrotto può sembrare un lock di backup abbandonato finché non vengono associati correttamente l'operazione e il proprietario.

Se un processo è attivo o i suoi log avanzano, attendi oppure arrestalo correttamente tramite il relativo gestore dei servizi. Se l'host non è raggiungibile, non è dimostrato che il lock sia obsoleto. Procedi solo quando ogni processo pertinente è assente, nessuna pianificazione può riavviarlo e il repository non sta ricevendo scritture.

Verifica che il lock sia obsoleto, non solo in base alla sua età

Attendi per un breve intervallo di osservazione e mostra nuovamente l'elenco dei lock. Un candidato obsoleto non ha proprietari attivi, log in avanzamento, aggiornamenti né attività di scrittura sul repository. Confronta gli orologi e interroga lo stesso backend da un altro client attendibile se il repository è remoto.

Un completo flusso di lavoro di un repository Restic considera lo sblocco una delle operazioni amministrative tra backup, controlli, conservazione e ripristini; non è un sostituto della determinazione di chi possiede ancora il repository.

Se il lock si aggiorna, se un log avanza o se i client non concordano sulla visualizzazione del backend, interrompi la procedura. Se il lock rimane invariato e il suo proprietario è certamente terminato, procedi. L'età supporta il risultato, ma non lo determina: un'operazione attiva e lenta può essere più vecchia di quanto l'operatore si aspetti.

Usa prima la pulizia standard dei lock obsoleti

Usa il normale comportamento di sblocco di Restic, in modo che rimuova i lock obsoleti preservando quelli che considera ancora attivi. Non aggiungere un'opzione per rimuovere tutto e non eseguire il comando successivo senza bloccare il repository. Salva l'output del comando e acquisisci subito dopo un nuovo elenco dei lock.

Il comando di sblocco standard è specificamente destinato ai lock obsoleti, mentre la rimozione forzata è un'azione separata e più rischiosa che non dovrebbe rientrare nella normale sequenza di riparazione.

Se la voce obsoleta scompare e non viene rimosso alcun lock attivo, procedi con la convalida. Se rimane un lock attivo, rispettalo e torna alla verifica del proprietario. Se un lock ricompare immediatamente, un timer, un container o un host remoto ha avviato un'attività; disabilita quella fonte e non ripetere lo sblocco finché il nuovo proprietario non è stato identificato.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Convalida il backup originale e la successiva esecuzione pianificata

Esegui il backup esatto che era stato bloccato e registra l'avvio, l'avanzamento, lo stato di uscita e il ciclo di vita del lock. Verifica che il lock compaia mentre Restic è in esecuzione e scompaia dopo un'uscita corretta. Elenca il nuovo snapshot e ripristina un piccolo campione in una posizione separata prima di riattivare l'automazione.

Se il repository si comporta come se fosse di sola lettura o la manutenzione rimane incompleta, mantieni lo stato di prune interrotto separato dalla pulizia dei lock obsoleti.

Riattiva la pianificazione normale per un ciclo. La riparazione è riuscita quando entrambe le esecuzioni terminano, i relativi lock vengono eliminati normalmente e il campione ripristinato corrisponde all'originale. Procedi con l'escalation se un lock obsoleto ricompare dopo l'uscita corretta del processo, le visualizzazioni del backend rimangono incoerenti o i risultati del controllo e del ripristino del repository non coincidono. Non automatizzare lo sblocco forzato come soluzione alla ricorrenza.