fssync - En ligne dans le Cloud

PROGRAMME:

Nom

fssync - Outil de synchronisation du système de fichiers (1 voie, via SSH)

SYNOPSIS

fssync -d db -r racine [option...] hôte

DESCRIPTION

fssync est un outil de synchronisation de fichiers unidirectionnel qui suit les inodes et maintient un
base de données de fichiers qui se trouvent sur le côté distant, ce qui lui permet de :

· gérer efficacement un grand nombre de répertoires/fichiers

· détecter les renommages/déplacements et les liens physiques

Il vise à minimiser le trafic réseau et à synchroniser chaque détail d'un système de fichiers :

· tous types d'inode : fichier, répertoire, bloc/caractère/fifo, socket, lien symbolique

· préserver les liens durs

· heure de modification, propriété/autorisation/ACL, attributs étendus

· fichiers épars

Autres caractéristiques :

· il peut être configuré pour exclure des fichiers de la synchronisation

· fssync peut être interrompu et repris à tout moment, ce qui le rend tolérant aux échecs aléatoires
(par exemple, erreur de réseau)

· l'algorithme pour synchroniser le contenu du fichier est conçu pour gérer les gros fichiers comme les images de VM
efficacement, en mettant à jour les blocs modifiés de taille fixe sur place

L'utilisation principale de fssync est d'empêcher la perte de données en cas de panne matérielle, où RAID1 est
pas possible (par exemple dans les ordinateurs portables).

On Btrfs [1] systèmes de fichiers, fssync est une alternative utile à btrfs envoyer (Et recevoir)
commandes, grâce aux capacités de filtrage. Cela peut être combiné avec le snapshotting Btrfs
côté destination pour une solution de sauvegarde complète.

UTILISATION

Utilisez fssync --Aidez-moi pour obtenir la liste complète des options.

La chose la plus importante à retenir est que la base de données locale doit correspondre exactement à ce qui est
sur l'hôte de destination :

· Les fichiers copiés sur l'hôte de destination ne doivent pas être modifiés. Et rien ne devrait
être créés manuellement dans les répertoires de destination. Si vous souhaitez toujours accéder aux données sur
hôte distant, vous devez le faire via un montage de liaison en lecture seule (nécessite Linux >=
2.6.26).

· Vous devez avoir 1 base de données par destination, si vous prévoyez d'avoir plusieurs copies de la même
répertoire source.

Regarde -c option si vous vous demandez si votre base de données correspond au répertoire de destination.

Première exécution de fssync :

· Le moyen le plus simple est de laisser fssync faire tout. Spécifiez un chemin de fichier inexistant vers -d
et un répertoire de destination vide ou inexistant (voir -R option). fssync va
crée automatiquement la base de données et copie tous les répertoires/fichiers sur l'hôte distant.

· Un moyen plus rapide peut être de faire la copie initiale par d'autres moyens, comme une copie brute d'un
cloison. Si vous êtes absolument sûr que la source et la destination sont exactement les mêmes,
vous pouvez initialiser la base de données en spécifiant - comme hôte. Si les numéros d'inode sont les mêmes
des deux côtés, ce qui est le cas si les données ont été copiées au niveau du bloc, vous pouvez modifier le
partition source pendant que vous initialisez la base de données sur la destination, et revenez
la base de données localement.

Un exemple de wrapper autour de fssync, avec un filtre, peut être trouvé sur exemples/fssync_home

fssync ne descend jamais les répertoires sur d'autres systèmes de fichiers. Inodes masqués par des points de montage
sont également ignorés, ils doivent donc être démontés temporairement si vous voulez qu'ils soient
synchronisé. Le même résultat peut être obtenu en synchronisant à partir d'un montage lié.

Voir aussi NONE zéro de commutation [2] patch si vous n'avez pas besoin de cryptage et que vous voulez
accélérez votre connexion SSH.

COMMENT IT TRAVAUX

fssync maintient une seule table SQLite de tous les répertoires/fichiers qui se trouvent du côté distant. Chaque
ligne correspond à un chemin, avec son inode (sur le côté local), d'autres métadonnées (sur le côté distant) et un
vérifié drapeau.

Lors de l'exécution, fssync parcourt de manière récursive tous les répertoires/fichiers locaux et pour chaque chemin
qui n'est pas ignoré (voir -f option), il interroge la base de données pour décider quoi faire. Si déjà
vérifié, le chemin est immédiatement ignoré. Lorsqu'un chemin est synchronisé, il est marqué comme
vérifié. A la fin, toutes les lignes qui ne sont pas vérifié correspond à des chemins qui n'existent pas
plus. Une fois qu'ils sont supprimés du côté distant, tous vérifié les drapeaux sont réinitialisés.

Échec tolérance
En fait, fssync n'exige pas que la base de données corresponde parfaitement à la destination. Ce
tolère quelques différences afin de récupérer toute synchronisation interrompue causée par un
panne de réseau, erreur d'opération de fichier ou autre chose qu'un plantage du système d'exploitation
de l'hôte local (ou quelque chose de similaire comme une panne de courant).

Dans la plupart des cas, cela est fait par l'hôte distant, qui crée (ou écrase) automatiquement
un inode du type attendu si nécessaire. La seule exception est que la télécommande
ne supprimez jamais seul un répertoire non vide. Pour les cas les plus complexes, fssync journalise
l'opération dans la base de données : en cas d'échec, fssync pourra récupérer au prochain
synchroniser.

Race conditions
Une condition de concurrence signifie que d'autres processus sur l'hôte local modifient des inodes qui
fssync se synchronise. fssync gère tout type de condition de concurrence. En fait, fssync a
rien à faire pour la plupart des cas.

Lorsqu'une condition de concurrence se produit, fssync ne garantit pas que les données distantes sont dans un
état cohérent. Chaque synchronisation corrige toujours les incohérences existantes mais peut introduire
d'autres, fssync n'est donc pas adapté à la sauvegarde à chaud des bases de données.

Avec Btrfs, vous pouvez obtenir une cohérence en prenant des instantanés côté source.

SIMILAIRE PROJETS

L'idée de maintenir une base de données locale vient en fait de csync2 [3]. j'étais sur le point de
l'adopter quand j'ai réalisé que j'avais vraiment besoin d'un outil qui détecte toujours les renommages/déplacements de
gros fichiers. C'est pourquoi je vois fssync comme une réécriture partielle de csync2, avec suivi des inodes et
sans synchronisation bidirectionnelle. La base de données locale fait vraiment fssync & csync2
plus rapide que le bien connu rsync [4].

Utiliser fssync en ligne à l'aide des services onworks.net