Disclaimer: dato che non ho mai usato zvols, non posso dire se sono diversi nella replica rispetto ai normali filesystem o istantanee. Presumo che lo siano, ma non credetemi.
La tua domanda è in realtà più domande, provo a rispondere separatamente:
Come replicare / eseguire il mirroring del pool completo nella posizione remota
È necessario dividere l'attività in due parti: in primo luogo, la replica iniziale deve essere completa, successivamente è possibile la replica incrementale, purché non si scherzi con le istantanee della replica . Per abilitare la replica incrementale, è necessario preservare le ultime istantanee della replica, tutto ciò che può essere eliminato prima. Se si elimina l'istantanea precedente, zfs recvsi lamenterà e si interromperà la replica. In questo caso devi ricominciare tutto da capo, quindi cerca di non farlo.
Se hai solo bisogno delle opzioni corrette, sono:
zfs send:
-R: invia tutto nel pool o nel set di dati indicato (replica ricorsiva, necessaria in ogni momento, include -p). Inoltre, durante la ricezione, tutti gli snapshot di origine eliminati vengono eliminati sulla destinazione.-I: include tutte le istantanee intermedie tra l'ultima istantanea di replica e l'attuale istantanea di replica (necessaria solo con invii incrementali)
zfs recv:
-F: espande il pool di destinazione, inclusa l'eliminazione di set di dati esistenti che vengono eliminati sull'origine-d: elimina il nome del pool di origine e lo sostituisce con il nome del pool di destinazione (il resto dei percorsi del file system verrà conservato e, se necessario, anche creato)-u: non montare il filesystem sulla destinazione
Se preferisci un esempio completo, ecco un piccolo script:
#!/bin/sh
# Setup/variables:
# Each snapshot name must be unique, timestamp is a good choice.
# You can also use Solaris date, but I don't know the correct syntax.
snapshot_string=DO_NOT_DELETE_remote_replication_
timestamp=$(/usr/gnu/bin/date '+%Y%m%d%H%M%S')
source_pool=tank
destination_pool=tank
new_snap="$source_pool"@"$snapshot_string""$timestamp"
destination_host=remotehostname
# Initial send:
# Create first recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Initial replication via SSH.
zfs send -R "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Incremental sends:
# Get old snapshot name.
old_snap=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$source_pool"@"$snapshot_string" | tail --lines=1)
# Create new recursive snapshot of the whole pool.
zfs snapshot -r "$new_snap"
# Incremental replication via SSH.
zfs send -R -I "$old_snap" "$new_snap" | ssh "$destination_host" zfs recv -Fdu "$destination_pool"
# Delete older snaps on the local source (grep -v inverts the selection)
delete_from=$(zfs list -H -o name -t snapshot -r "$source_pool" | grep "$snapshot_string" | grep -v "$timestamp")
for snap in $delete_from; do
zfs destroy "$snap"
done
Usa qualcosa di più veloce di SSH
Se si dispone di una connessione sufficientemente protetta, ad esempio tunnel IPSec o OpenVPN e una VLAN separata esistente solo tra mittente e destinatario, è possibile passare da SSH a alternative non crittografate come mbuffer come descritto qui , oppure è possibile utilizzare SSH con crittografia debole / assente e disabilitato la compressione, che è dettagliata qui . C'era anche un sito web sulla ricomposizione di SSH per essere molto più veloce, ma sfortunatamente non ricordo l'URL - lo modificherò più tardi se lo trovo.
Per set di dati molto grandi e connessioni lente, può anche essere utile alla prima trasmissione tramite disco rigido (utilizzare il disco crittografato per archiviare zpool e trasmetterlo in un pacchetto sigillato tramite corriere, posta o di persona). Poiché il metodo di trasmissione non ha importanza per send / recv, è possibile reindirizzare tutto sul disco, esportare il pool, inviare il disco a destinazione, importare il pool e quindi trasmettere tutti gli invii incrementali tramite SSH.
Il problema con le istantanee incasinate
Come indicato in precedenza, se si eliminano / modificano le istantanee della replica, verrà visualizzato il messaggio di errore
cannot send 'pool/fs@name': not an earlier snapshot from the same fs
il che significa che il tuo comando era sbagliato o sei in uno stato incoerente in cui devi rimuovere le istantanee e ricominciare tutto da capo.
Ciò ha diverse implicazioni negative:
- Non è possibile eliminare uno snapshot di replica fino a quando il nuovo snapshot di replica non è stato trasferito correttamente. Poiché queste istantanee di replica includono lo stato di tutte le altre (vecchie) istantanee, lo spazio vuoto dei file e delle istantanee cancellate verrà recuperato solo al termine della replica. Ciò può comportare problemi di spazio temporanei o permanenti sul pool che è possibile risolvere solo riavviando o completando la procedura di replica completa.
- Avrai molte snapshot aggiuntive, che rallentano il comando list (tranne su Oracle Solaris 11, dove è stato risolto).
- Potrebbe essere necessario proteggere le istantanee dalla rimozione (accidentale), ad eccezione dello script stesso.
Esiste una possibile soluzione a questi problemi, ma non l'ho provato da solo. È possibile utilizzare zfs bookmarkuna nuova funzionalità di OpenSolaris / illumos creata appositamente per questa attività. Questo ti libererebbe dalla gestione delle istantanee. L'unico aspetto negativo è che al momento funziona solo per singoli set di dati, non ricorsivamente. Dovresti salvare un elenco di tutti i tuoi set di dati vecchi e nuovi e quindi scorrere su di essi, aggiungere segnalibri, inviarli e riceverli, quindi aggiornare l'elenco (o il piccolo database, se preferisci).
Se provi il percorso dei segnalibri, sarei interessato a sapere come ha funzionato per te!
zfs send -R ...? Se hai reindirizzato l'output tramitessh, hai disabilitato i caratteri di escape conzfs send -R ... | ssh -e none ...?