Perché un backup Restic si blocca quando un altro host avvia la potatura?
Il backup di solito si blocca perché prune richiede il controllo esclusivo del repository condiviso, quindi in quel momento il secondo host non può continuare a utilizzare lo stesso stato del repository.
In una configurazione domestica con più host, la sequenza temporale è il primo elemento discriminante: il backup procede normalmente, un altro computer avvia prune e il backup attende oppure segnala un lock. Verifica il proprietario del lock e il log di manutenzione attivo prima di intervenire. Lascia terminare prune oppure arrestalo correttamente dall'host proprietario; non rimuovere mai il suo lock dal client del backup in attesa.
Conferma che prune sia la causa esatta
Salva il log del backup in attesa e il log di manutenzione dell'host che esegue prune, includendo i timestamp. Elenca i lock del repository e confronta host, processo e stato esclusivo con il processo prune. La causa è confermata quando l'avanzamento del backup si interrompe dopo che prune acquisisce il repository e riprende dopo il rilascio del lock.
Gli operatori che usano un unico repository da più host segnalano contesa durante il pruning perché l'operazione di manutenzione entra in competizione con pianificazioni di backup altrimenti indipendenti.
Se il backup era già lento, l'host che esegue prune non ha mai ottenuto un lock oppure entrambi i log si interrompono a causa di un errore di archiviazione, non forzare questa diagnosi. Controlla la disponibilità del backend, la latenza e il processo di backup stesso. La spiegazione del lock di prune si applica solo quando causa, proprietario del lock e tempistiche di rilascio coincidono.
Considera il lock esclusivo un limite di sicurezza
Prune modifica lo spazio di archiviazione del repository e quindi necessita di una vista coerente durante l'operazione. Il backup in attesa non è necessariamente bloccato nel senso comune del processo; potrebbe semplicemente rispettare il lock di manutenzione. La prima domanda è se prune stia avanzando, non come fare in modo che il backup ignori il lock.
Un'architettura con repository condiviso richiede un unico responsabile della manutenzione perché la manutenzione dell'intero repository influisce su ogni client, anche quando i dati di origine appartengono a host diversi.
Se i log di prune avanzano e l'I/O del repository continua, lascia il lock attivo e attendi il completamento del processo. Se il processo è realmente bloccato, arrestalo correttamente dall'host che lo possiede e attendi la chiusura completa. Rimuovere il lock da un altro client mentre prune sta ancora scrivendo trasforma un'attesa controllata in una sovrapposizione rischiosa.
Ripristina il backup in attesa senza aggirare il locking
La soluzione meno invasiva consiste nell'attendere il completamento di prune. Se il backup dispone di una politica di nuovi tentativi con limite, lascia che riprovi dopo la scomparsa del lock esclusivo. Quando è necessario arrestare prune, usa il gestore dei servizi o il supervisore dei processi sull'host proprietario, attendi l'arresto e verifica che l'elenco dei lock sia cambiato prima di riavviare il backup.
La conservazione può essere limitata per host, ma il recupero fisico dello spazio resta un'operazione sul repository. Una politica di conservazione con ambito per host impedisce di selezionare gli snapshot sbagliati; non rende sicuro eseguire prune contemporaneamente per client di backup non correlati.
Riprova il backup in attesa usando il locking ordinario. Se viene completato, la correzione corrisponde alla causa confermata. Se un altro processo prune si avvia immediatamente, disabilita la pianificazione di manutenzione duplicata. Se il backup continua a bloccarsi senza un lock esclusivo, non aumentare ulteriormente i tentativi e torna alla diagnostica del backend, della rete, della scansione dell'origine o del processo.
Ripeti il test della sovrapposizione originale e definisci il limite
Usa una finestra controllata con log completi. Avvia un backup normale, quindi richiama il controller di manutenzione pianificato e verifica che non crei una sovrapposizione rischiosa. Ripeti nell'ordine previsto con prune avviato per primo e verifica che il backup attenda o termini secondo la politica configurata, quindi abbia successo dopo il rilascio del lock.
Se un prune interrotto lascia il repository in uno stato operativo diverso, segui la diagnosi del prune interrotto invece di trattare ogni errore successivo come una normale contesa.
Il ripristino è riuscito quando la sovrapposizione originale viene gestita in modo prevedibile, il backup termina successivamente, prune si chiude correttamente e uno snapshot di esempio può essere ripristinato. Procedi con un'escalation se il lock non viene mai aggiornato o rilasciato, più host continuano ad avviare la manutenzione oppure un controllo del repository segnala danni. Questi risultati vanno oltre la singola causa del prune in esecuzione.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Come pianificare i processi Restic di backup, Forget e Prune senza conflitti di blocco
Una pianificazione completa di Restic per più host, che separa i backup frequenti, la conservazione con ambito definito, il prune fisico, i controlli, i...
Come impedire che i processi di eliminazione di Restic blocchino i backup programmati
Un piano di prevenzione per i repository Restic condivisi che separa le finestre di backup da prune e mantiene intatti i blocchi, i tentativi...
Come rimuovere un blocco Restic obsoleto senza interrompere un backup attivo
Un flusso di sblocco di Restic il meno invasivo possibile, che protegge i backup attivi, rimuove solo lo stato obsoleto e conferma il ripristino...
