Perché un repository di backup con deduplicazione funziona in sola lettura dopo un’operazione di eliminazione interrotta?

Un repository può comportarsi come se fosse di sola lettura dopo un prune interrotto, quando un blocco esclusivo, un errore di archiviazione, un backend immutabile o uno stato di manutenzione incompleto impediscono le modifiche.

“Sola lettura” può essere una risposta di sicurezza del client di backup, non necessariamente la modalità di montaggio effettiva del filesystem. Un prune annullato può lasciare un blocco esclusivo, operazioni incomplete sui pack o sugli indici, spazio di lavoro insufficiente per la pulizia oppure operazioni del backend che consentono la lettura ma rifiutano le eliminazioni. Separatamente, il sistema operativo può rimontare in sola lettura il filesystem del repository dopo errori di I/O o di coerenza. Individua il livello che rifiuta la prima scrittura prima di rimuovere i blocchi o rieseguire il prune.

Acquisisci la prima operazione che segnala la modalità di sola lettura

Esegui un comando per elencare i contenuti del repository, quindi un controllo non distruttivo, e salva il primo errore proveniente dai log del client, del backend e del sistema operativo.

La documentazione di Restic spiega che il prune riscrive i dati del repository e richiede l’accesso esclusivo perché rimuove i contenuti non referenziati e può ricompattare i file utilizzati solo parzialmente.

Se l’elenco dei contenuti funziona ma ogni operazione che crea un blocco o scrive metadati fallisce, distingui tra blocco obsoleto, autorizzazioni di scrittura del backend e conservazione degli oggetti.

Controlla la presenza di un blocco esclusivo lasciato dal prune interrotto

Elenca i blocchi del repository tramite lo strumento di backup e identifica l’host, il processo, l’ora di creazione e il comando proprietario di ciascun blocco.

Borg documenta che i comandi che modificano il repository utilizzano blocchi del repository per impedire scritture simultanee e avverte che interrompere un blocco attivo può danneggiare lo stato del repository.

Rimuovi un blocco obsoleto solo tramite il comando supportato e soltanto dopo aver dimostrato che il processo proprietario non è più in esecuzione.

Determina se il filesystem è stato rimontato in sola lettura

Controlla la tabella dei montaggi, il log del kernel, lo stato di salute del filesystem, lo stato del pool di archiviazione e gli errori recenti di USB, SATA, rete o controller.

La documentazione Linux di ext4 elenca errors=remount-ro come politica di sicurezza, mostrando come un guasto di archiviazione possa rendere il repository effettivamente di sola lettura.

Non forzare il rimontaggio in lettura-scrittura mentre gli errori hardware o del filesystem continuano. Conserva i log e ripara prima l’archiviazione.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Esamina lo stato parziale di prune, compact o dell’indice

Determina quale fase è stata interrotta: selezione degli snapshot scaduti, eliminazione dei riferimenti, repacking dei dati, ricostruzione di un indice o conferma dei metadati.

Il riferimento di Borg al prune osserva che prune e compact sono fasi separate, quindi gli archivi possono rimanere validi mentre il recupero dello spazio è incompleto.

Usa il comando di controllo del repository prima di un’altra esecuzione distruttiva. Non eliminare mai manualmente pack, indici o segmenti.

Controlla il blocco degli oggetti, l’immutabilità e le credenziali del backend

Per i repository cloud, controlla la conservazione degli oggetti, il blocco legale, i criteri del bucket, il versioning, i permessi di eliminazione e la rotazione delle credenziali.

AWS afferma che S3 Object Lock impedisce l’eliminazione o la sovrascrittura durante un periodo di conservazione protetto, consentendo le letture mentre il prune fallisce.

Non indebolire la conservazione immutabile solo per permettere il completamento del prune. Usa una progettazione del repository supportata dallo strumento di backup.

Verifica lo spazio libero, gli inode e l’area di lavoro del prune

Controlla i byte disponibili del filesystem, gli inode, le quote, lo spazio riservato agli snapshot, le directory temporanee, i limiti dell’object storage e lo spazio della cache locale.

GNU Coreutils spiega che df può riportare i blocchi e l’utilizzo degli inode, distinguendo un filesystem pieno da un blocco o da un errore di autorizzazione a livello di repository.

Se il filesystem è pieno, aggiungi capacità temporanea o rimuovi dati non correlati e verificati invece di eliminare oggetti del repository.

Ripristina il servizio con check, unlock e un’unica esecuzione controllata di manutenzione

Proteggi gli ultimi punti di ripristino sicuramente validi, interrompi le pianificazioni, esegui un controllo supportato, cancella solo un blocco sicuramente obsoleto ed esegui una singola operazione di manutenzione registrata nei log.

La guida di ZimaSpace al ripristino di una destinazione di backup piena fornisce la regola correlata: tratta il repository come una struttura gestita, non come un insieme di file indipendenti.

Il problema è risolto quando l’elenco dei contenuti, il controllo, il backup, la conservazione e un ripristino di prova hanno tutti esito positivo senza sblocchi forzati o eliminazioni manuali.

Domande frequenti

Posso eliminare manualmente il file di blocco?

Non come primo passo. Verifica che nessun processo ne sia proprietario e usa l’operazione di sblocco supportata dallo strumento di backup.

Devo rieseguire immediatamente il prune dopo un arresto anomalo?

No. Verifica lo stato del repository, dell’indice, del filesystem e del backend prima di un’altra operazione di manutenzione distruttiva.

Il comportamento di sola lettura significa che i dati di backup sono al sicuro?

Non necessariamente. Pack mancanti, errori di archiviazione, oggetti immutabili o indici incompleti possono comunque impedire i ripristini.