fssync - Online nel cloud

PROGRAMMA:

NOME

fssync - Strumento di sincronizzazione del file system (a una via, su SSH)

SINOSSI

fsync -d db -r radice [opzione...] host

DESCRIZIONE

fssync è uno strumento di sincronizzazione dei file unidirezionale che tiene traccia degli inode e mantiene un locale
database di file che si trovano sul lato remoto, rendendolo in grado di:

· gestire in modo efficiente un numero enorme di directory/file

· rilevare rinomina/mosse e hard-link

Mira a ridurre al minimo il traffico di rete e a sincronizzare ogni dettaglio di un file system:

· tutti i tipi di inode: file, dir, block/character/fifo, socket, symlink

· preservare gli hard link

· tempo di modifica, proprietà/permesso/ACL, attributi estesi

· file sparsi

Altre caratteristiche:

· può essere configurato per escludere i file dalla sincronizzazione

· fssync può essere interrotto e ripreso in qualsiasi momento, rendendolo tollerante a guasti casuali
(es. errore di rete)

· l'algoritmo per sincronizzare il contenuto dei file è progettato per gestire file di grandi dimensioni come le immagini VM
in modo efficiente, aggiornando sul posto i blocchi modificati di dimensione fissa

L'uso principale di fssync è prevenire la perdita di dati in caso di guasto hardware, dove è RAID1
non possibile (ad es. nei laptop).

On Btrfs [1] file system, fssync è un'utile alternativa a btrfs inviare (E ricevere)
comandi, grazie alle capacità di filtraggio. Questo può essere combinato con lo snapshot di Btrfs
sul lato di destinazione per una soluzione di backup completo.

USO

Usa il fsync --Aiuto per ottenere l'elenco completo delle opzioni.

La cosa più importante da ricordare è che il database locale deve corrispondere esattamente a ciò che è
sull'host di destinazione:

· I file copiati sull'host di destinazione non devono essere modificati. E niente dovrebbe
essere creato manualmente all'interno delle directory di destinazione. Se vuoi comunque accedere ai dati su
host remoto, dovresti farlo tramite un bind di sola lettura monta (richiede Linux >=
2.6.26).

· Devi avere 1 database per destinazione, se prevedi di avere più copie dello stesso
directory di origine.

Guarda a -c opzione se ti chiedi se il tuo database corrisponde alla directory di destinazione.

Prima esecuzione di fssync:

· Il modo più semplice è lasciare che fssync faccia tutto. Specificare un percorso file inesistente a -d
opzione e una directory di destinazione vuota o inesistente (vedi -R opzione). fssync lo farà
crea automaticamente il database e copia tutte le directory/file sull'host remoto.

· Un modo più veloce potrebbe essere quello di eseguire la copia iniziale con altri mezzi, come una copia grezza di a
partizione. Se sei assolutamente sicuro che l'origine e la destinazione siano esattamente le stesse,
puoi inizializzare il database specificando - come ospite. Se i numeri di inode sono gli stessi
su entrambi i lati, come nel caso in cui i dati siano stati copiati a livello di blocco, è possibile modificare il
partizione di origine mentre si inizializza il DB su quello di destinazione e tornare indietro
il DB localmente.

Un esempio di wrapper intorno a fssync, con un filtro, può essere trovato su esempi/fssync_home

fssync non discende mai le directory su altri filesystem. Inode mascherati da punti di montaggio
sono anche saltati, quindi dovrebbero essere smontati temporaneamente se vuoi che lo siano
sincronizzato. Lo stesso risultato può essere ottenuto sincronizzando da un montaggio bind.

Vedi anche il NONE cifra commutazione [2] patch se non hai bisogno di crittografia e vuoi
velocizza la tua connessione SSH.

COME IT OPERE

fssync mantiene una singola tabella SQLite di tutte le directory/file che si trovano sul lato remoto. Ogni
la riga corrisponde a un percorso, con il suo inode (sul lato locale), altri metadati (sul lato remoto) e a
controllato bandiera.

Durante l'esecuzione, fssync itera in modo ricorsivo su tutte le directory/file locali e per ogni percorso
che non viene ignorato (vedi -f opzione), interroga il DB per decidere cosa fare. Se già
controllato, il percorso viene saltato immediatamente. Quando un percorso è sincronizzato, è contrassegnato come
controllato. Alla fine, tutte le righe che non lo sono controllato corrisponde a percorsi che non esistono
più. Una volta eliminati sul lato remoto, tutto controllato i flag vengono ripristinati.

Fallimento tolleranza
Infatti, fssync non richiede che il database corrisponda perfettamente alla destinazione. Esso
tollera alcune differenze al fine di recuperare qualsiasi sincronizzazione interrotta causata da a
un errore di rete, un errore di operazione sui file o qualsiasi cosa diversa da un arresto anomalo del sistema operativo
dell'host locale (o qualcosa di simile come un'interruzione di corrente).

Nella maggior parte dei casi, questo viene fatto dall'host remoto, che crea (o sovrascrive) automaticamente
un inode del tipo previsto, se necessario. L'unica eccezione è che il telecomando lo farà
non eliminare mai una directory non vuota da sola. Per i casi più complessi, fssync pubblica il giornale
l'operazione nel database: in caso di errore, fssync sarà in grado di recuperare al prossimo
sync.

Gara condizioni
Una race condition significa che altri processi sull'host locale stanno modificando gli inode che
fssync è in fase di sincronizzazione. fssync gestisce qualsiasi tipo di race condition. In effetti, fssync ha
niente da fare per la maggior parte dei casi.

Quando si verifica una race condition, fssync non garantisce che i dati remoti siano in a
stato coerente. Ogni sincronizzazione corregge sempre le incongruenze esistenti ma potrebbe introdurre
altri, quindi fssync non è adatto per il backup a caldo dei database.

Con Btrfs, puoi ottenere coerenza effettuando snapshot sul lato sorgente.

SIMILE RECENTI

L'idea di mantenere un database locale in realtà deriva da csync2 [3]. stavo per
adottarlo quando mi sono reso conto che avevo davvero bisogno di uno strumento che rilevasse sempre rinomina/mosse di
file di grandi dimensioni. Ecco perché vedo fssync come una riscrittura parziale di csync2, con tracciamento inode e
senza sincronizzazione bidirezionale. Il database locale rende davvero fssync e csync2
più veloce del noto rsync [4].

Utilizzare fssync online utilizzando i servizi onworks.net