Perché un token di ripresa di ZFS Send smette di funzionare dopo il riavvio della destinazione?
Un riavvio della destinazione normalmente non dovrebbe invalidare un token di ripresa ZFS, a meno che non siano cambiati lo stato di ricezione salvato, il dataset o la cronologia sorgente necessaria.
Il token è una descrizione opaca di una specifica ricezione interrotta, non un segnalibro riutilizzabile per qualsiasi tentativo di replica successivo. Appartiene al filesystem o al volume di destinazione che ha conservato lo stato parziale con una ricezione riprendibile. Dopo un riavvio, un'attività potrebbe leggere il dataset sbagliato, importare il pool in modo diverso, cancellare lo stato parziale, modificare la destinazione, perdere uno snapshot sorgente necessario o generare uno stream incompatibile. Verifica il token su entrambi i lati prima di riavviare un trasferimento completo.
Conferma che lo stato della ricezione parziale sia sopravvissuto al riavvio
Sulla destinazione, leggi la proprietà receive_resume_token dal filesystem o volume esatto utilizzato dalla ricezione interrotta. Registra il nome del pool, il percorso del dataset, il valore del token e lo spazio utilizzato dallo stato parziale.
Il manuale di FreeBSD spiega che le ricezioni riprendibili conservano lo stato parziale e mantengono un token opaco sul dataset ricevente finché il trasferimento non viene completato o lo stato non viene abbandonato esplicitamente.
Se la proprietà è vuota dopo il riavvio, la ricezione non è stata salvata con l'opzione di ripresa, lo stato parziale è stato completato o interrotto, è in corso una query sul dataset sbagliato oppure una procedura automatizzata lo ha rimosso. Non riutilizzare un token copiato da un trasferimento precedente.
Verifica che il token appartenga al dataset di destinazione esatto
Controlla se il pool è stato importato con il nome previsto e se la replica punta ancora allo stesso percorso del dataset. Presta attenzione a root alternative, pool rinominati, modifiche al percorso padre e opzioni dell'attività che aggiungono o rimuovono componenti del percorso.
Il riferimento alle proprietà ZFS di Ubuntu definisce receive_resume_token come proprietà di un dataset, il che significa che il token deve essere letto dal filesystem o volume che contiene quello specifico stato salvato.
Non si può presumere in sicurezza che un token recuperato da backup/pool/data possa riprendere una ricezione ora indirizzata a backup/data. Correggi il percorso dell'attività prima di modificare gli snapshot o distruggere la ricezione parziale.
Controlla se la destinazione è stata modificata o ripristinata
Esamina i comandi, le attività pianificate, il software di replica, la conservazione degli snapshot e le attività dell'amministratore dall'interruzione in poi. Cerca ripristini, promozioni di cloni, rinomina del dataset, interruzioni della ricezione o una nuova ricezione nella stessa destinazione.
Klara Systems osserva che gli strumenti di replica gestiscono lo stato della destinazione durante le operazioni ZFS send e receive; pertanto, un'attività di orchestrazione può invalidare il percorso di ripristino originale ripulendo o sostituendo lo stato salvato.
Durante l'analisi, non scrivere file normali nella destinazione della replica. Anche quando il token esiste ancora, le modifiche alla destinazione possono bloccare lo stream o forzare un ripristino che distrugge i dati più recenti della destinazione.
Verifica che la sorgente disponga ancora della catena di snapshot o bookmark
Identifica il dataset sorgente e gli snapshot o bookmark codificati nel trasferimento interrotto. Confrontali con la conservazione attuale e con eventuali rinominazioni o eliminazioni di snapshot avvenute dopo l'interruzione del trasferimento.
Il manuale zfs-send di FreeBSD specifica che zfs send -t genera uno stream dal token di ripresa della ricezione, collegando il nuovo stream alla ricezione interrotta anziché a uno snapshot corrente qualsiasi.
Se la conservazione ha eliminato la cronologia sorgente necessaria, il token non può ricostruire dati che non esistono più. Conserva lo stato parziale rimanente sulla destinazione finché non avrai deciso se è necessaria un'altra copia sorgente o un nuovo invio completo.
Controlla le funzionalità del pool e le opzioni dello stream su entrambi i sistemi
Registra le versioni di ZFS, le funzionalità abilitate del pool, lo stato della crittografia e le opzioni originali dello stream, come invii raw, compressi, embedded o con blocchi grandi. Confrontali dopo qualsiasi aggiornamento del software o del pool.
La documentazione Oracle sulla replica riprendibile descrive la ripresa di un trasferimento interrotto come un'operazione coordinata di invio e ricezione; pertanto, la compatibilità e il contesto del trasferimento originale restano importanti anche dopo un riavvio.
Un semplice riavvio non modifica i flag delle funzionalità, ma un aggiornamento eseguito durante l'interruzione può farlo. Riproduci manualmente il comando di ripresa con un output dettagliato prima di presumere che il token sia danneggiato.
Verifica i servizi di replica e SSH dopo l'avvio della destinazione
Conferma che il pool di destinazione sia importato, che i dataset crittografati necessari siano sbloccati, che SSH sia in esecuzione, che l'utente di replica possa eseguire comandi ZFS e che l'attività venga avviata solo dopo che lo storage è pronto.
Le indicazioni TrueNAS sulla replica remota richiedono che i prerequisiti SSH e del dataset di destinazione siano disponibili dopo il riavvio; in caso contrario, l'automazione può fallire prima ancora di tentare l'uso del token salvato.
Testa l'autenticazione e una query di sola lettura delle proprietà prima di avviare lo stream ripreso. Un errore di rete o di autorizzazione può sembrare un errore del token nei log di un'attività di livello superiore.
Riprendi una volta oppure interrompi deliberatamente la ricezione parziale
Genera uno stream ripreso utilizzando il token corrente e passalo a una ricezione riprendibile sulla stessa destinazione. Salva l'output completo dell'errore ed evita di avviare attività di replica parallele.
La guida alla migrazione dei dati NAS di ZimaSpace fornisce la regola di sicurezza correlata: conserva la sorgente e il percorso di ripristino finché la destinazione non è stata verificata.
Se il token non è utilizzabile e lo stato parziale non è più importante, interrompilo con il comando supportato per annullare la ricezione solo dopo aver confermato che sia possibile generare un trasferimento completo o incrementale sostitutivo. L'interruzione libera lo stato parziale salvato e non può essere annullata.
Domande frequenti
Un riavvio della destinazione invalida sempre un token di ripresa ZFS?
No. Una ricezione parziale salvata è progettata per sopravvivere alle interruzioni, incluso uno spegnimento anomalo. Un errore dopo il riavvio indica solitamente che l'attività sta leggendo un dataset diverso, che lo stato parziale è stato cancellato, che la cronologia sorgente necessaria è cambiata o che mancano dipendenze all'avvio.
È possibile generare un nuovo token di ripresa solo dalla sorgente?
No. Il token opaco proviene dallo stato parziale salvato della ricezione nel dataset di destinazione. La sorgente utilizza quel token per generare uno stream di continuazione, ma non può ricreare da sola uno stato di destinazione eliminato.
Quando è necessario interrompere la ricezione parziale?
Interrompila solo quando è stato dimostrato che il percorso di ripresa non è utilizzabile, la sorgente può generare un trasferimento sostitutivo e lo stato parziale della destinazione non è più necessario per il ripristino. Conserva i log e gli snapshot disponibili prima di rimuoverlo.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
