Bonjour Nicolas,
La commande "cp" ne sert qu a effectuer une copie fichie par fichier. La solution est tout de meme fiable avec ZFS car les donnees sont lues et copiees avec carlcul de parite (checksum). Cependant c ette operation a des limites car elle ne copie que l etat actuel des donnee presente sur le volume sans prendre en compte son histoire anterieur.
Pour mieux comprendre la distinction, on peut regarder quel est l impact des snaphsots.
Par exemple, tu cree un fichier sur ton volume, tu l edite et un jour tu le suprime. S'il n y as pas eu de snapshot pris pour le dataset, the fichier en question est perdue sans moyen de le recuperer.
Si par exemple tu utilise les snapshots, et que tu cre le fichier (des photos, video, bref ce que tu veux) et que tu a regulierement des snapshot pris a interval regulier par le systeme, un jour tu efface par erreur le fichier, et bien tu peu utiliser le snapshot existant afin de recuper le fichier en question par clonage.
ZFS fonctionne de la facon suivante. Quand un fichier est cree, le fichier est en fait ecrit sur le volume en plusieurs bloques. Chaque bloques contient une partie du fichier avec le checksum pour la detection de corruption. Quand tu prend un snapshot, tous les block existants sont figes sur le disque et ne peuvent donc maintenant etre modifie tans que le snapshot y faisant reference est toutjours present.
ZFS emploit la methode "COW" (Copy on Write) ce qui signifie que la donne n est faite qu'une seul fois et n est jamias modifie.
Quand le volume est cree pour la premiere fois, il ne contient aucun bloques. Des que les donnees y sont copies les blanques vont s ajouter les uns a la suite des autres et chaques block y est associer un index. Quand un snapshot est cree, le snapshot vas simplement cree la liste des blocques en enregistrant les index des bloques qui ont ete ajoute depuis le dernier snapshot. Le snapshot ne contient pas la totalite des index a moins quil ne soit le seul present.
Si tu efface un fichier dont les donnees sont ecrite sur des bloques qui sont deja pointe par des snapshot, alors ces donnees ne seront pas efface mais ZFS va changer les pointeur sur ces blocques pour indiquer qu'il n existe plus. Si tu liste le contenu du reprertoire en question, ce fichier va avoir disparue.
Avec les snapshots, tu peux utiliser la commande "zfs diff" pour comparer le contenu entre deux snapshots. Si on prend le cas du fichier efface, tu devais etre en mesure de voir que le fichier existe dans les snapshot precedent avant son effacement.
Rappelle toi que tant que le snapshot existe, le fichier (les bloques) sont toujours present.
Si tu decidait d effacer les snapshot contenant la liste des blocques pour ces fichier, alors tu va en effet perdre les fichier en question. Detruire un snapshot permet a ZFS de recuperer les blocks qui sont destine a ete effaces. Si le fichier est toujour present, alors les blocks faisant reference a ce fichier seront preserve.
Se qu'il faut retenir c'est que le snapshot ne retient que la liste des blocks qui sont ajoute ou detruit depuis le dernier snapshot.
Chaques dataset a sa propre serie de snapshot.
La commande "zfs send -R ..." execute la replication de facon recursive.
Si tu as un volume avec plusieurs datasets et que tu veux en faire une copie exacte, tu dois prendre un snapshot du volume et ce snapshot doit etre recursif.
Par exemple tu a ton volume "DATA", si tu effectue le snapshot de "DATA" de facon recursive, tous les dataset ce trouvanten dessous vont avoir leur propre snapshot de cree.
DATA@auto-xxx
DATA@manual-20181111
DATA\dataset1@auto-xxx
DATA\dataset1@manual-20181111
DATA\dataset1\sub-dataset@auto-xxx
DATA\dataset1\sub-dataset@manual-20181111
DATA\dataset2@manual-20181111
DATA\dataset2@auto-xxx
Pour la replication resursive tu utilise le dernier snapshot cree pour le volume ce qui te donne par exemple
zfs send -R DATA@manual-20181111 | zfs receive BACKUP
Avec cette methode tous les datasets et snapshot existants sur DATA vont se retrouver sur BACKUP et vont apparaitre de la facon suivante:
BACKUP@auto-xxx
BACKUP@manual-20181111
BACKUP\BACKUPset1@auto-xxx
BACKUP\BACKUPset1@manual-20181111
BACKUP\BACKUPset1\sub-BACKUPset@auto-xxx
BACKUP\BACKUPset1\sub-BACKUPset@manual-20181111
BACKUP\BACKUPset2@manual-20181111
BACKUP\BACKUPset2@auto-xxx
Si le snapshot existe sur BACKUP, ca signifie que le donnees existante sur DATA on ete repliquees. Ce n'est pas la peine d'en verifier le contenu.
Si pour une raison le snapshot n existe pas (par example due a une deconnection) le contenue present sur BACKUP ne serra pas completement perdu car tu suara que le dernier snapshot present contient deja une partie de tes donnes telle present e au momemtn de ce snapshot sur le volume DATA. Pour finaliser le transfer tu n as qu'a effectuer un transfert incremental entre le dernier snapshot present sur BACKUP et le dernier present sur DATA avec la commande suivante:
zfs send -I DATA.... DATA.....| zfs receive BACKUP....
Cet un peut plus complique a ceniveau car pendant une replication Recursive, l operation envoi tous les snapshot un dataset a la fois.
Donc s'il y a interuption, il faut reprendre uniquement la ou le dernier dataset avais commance.
Il est em principe possible de relancer la commande avec (mais j en suis pas certain:
zfs send -I DATA@auto-xxx DATA@manual-20181111 | zfs receive BACKUP@auto-xxx
Avec la commande "cp", la copie ne prend en compte que les fichiers visibles et non ceux qui n ete effacee ou modifier avant le dernier snapshot.
En plus, si la copy est interompue, tu n as aucun moyen fiable de dire quel sont les fichiers copier de ceut qui ne le sont pas. Il est aussi possible qu'un fichier bien que present a ll copie ne soit pas complet et donc se trouve corrompu. Avec cette approche, tu dois utilise rsync ou similaire pour comparer le contenu et renvoyer les donnees non copies.
Je crois aussi qu'avec la copie le transfer vas etre extremement long pour les petits fichier.
Avec la replication c'est different car meme si les fichier sont infinitesimalement petits mais que le snapshot pointe a tous, alors le transfert ce ferra comme si c etait un grand fichier, c est a dire tu peux facilement envoye 1 million de fichier de 1Mo a +100MB/s.
Avec la copie "cp" ce n'est pas le cas.
Il est aussi possible de preserver l etat du replication qui a ete interrompue, mais je n ais pas eu l occasion d y passer beaucoup de temps a l etudier.
C'est interressant dans le cas ou le volume contient des snapshot pointnant sur une quantite considrable et envoye pas media non fiable comme sur internet outoute deconnection est possible. Avec cette approche, tu est en mesure de reprendre a partir du dernier bloques replique au lieu du dernier snapshot.
Je te conseil de lire les information sur:
https://docs.oracle.com/
Pour plus de details, fair une recherche sur Google avec les termes:
"zfs replication"
et tu selection les sites contenent l adresse oracle ci dessus.
Bien que les information ne soient plus forcement pertinnentent, elle sont d'un grand recours.
