{"id":105367,"date":"2022-10-23T21:36:56","date_gmt":"2022-10-23T19:36:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-utilit-dlya-rezervnogo-kopirovaniya-rsync-3-2-7-i-rclone-1-60"},"modified":"2022-10-23T21:36:56","modified_gmt":"2022-10-23T19:36:56","slug":"vypusk-utilit-dlya-rezervnogo-kopirovaniya-rsync-3-2-7-i-rclone-1-60","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-utilit-dlya-rezervnogo-kopirovaniya-rsync-3-2-7-i-rclone-1-60","title":{"rendered":"Publication des outils de sauvegarde Rsync 3.2.7 et rclone 1.60","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
La publication de Rsync 3.2.7, un utilitaire pour la synchronisation de fichiers et la sauvegarde, permettant de minimiser le trafic gr\u00e2ce \u00e0 une copie incr\u00e9mentielle des changements. Les transports peuvent utiliser ssh, rsh ou le protocole rsync propri\u00e9taire. La gestion des serveurs rsync anonymes, optimales pour la synchronisation des miroirs, est prise en charge. Le code du projet est distribu\u00e9 sous la licence GPLv3. <\/p>\n
Parmi les modifications ajout\u00e9es : <\/p>\n
\n
L'utilisation des hachages SHA512, SHA256 et SHA1 est autoris\u00e9e lors de l'authentification de la connexion de l'utilisateur au processus en arri\u00e8re-plan rsync (auparavant, MD5 et MD4 \u00e9taient pris en charge).\n
La possibilit\u00e9 d'utiliser l'algorithme SHA1 pour le calcul des sommes de contr\u00f4le des fichiers a \u00e9t\u00e9 impl\u00e9ment\u00e9e. En raison de la taille importante du hachage, SHA1 se voit attribuer la plus basse priorit\u00e9 dans la liste de n\u00e9gociation des hachages. Pour forcer le choix de SHA1, l'option \u00ab\u00a0\u2014checksum-choice\u00a0\u00bb peut \u00eatre utilis\u00e9e.\n
Pour r\u00e9duire la probabilit\u00e9 d'apparition de collisions, la table de hachage des attributs xattr est pass\u00e9e \u00e0 l'utilisation de cl\u00e9s 64 bits.\n
Il est d\u00e9sormais possible d'afficher des informations sur les algorithmes pris en charge par rsync au format JSON (activ\u00e9 en dupliquant l'option \u2014version (\u00ab\u00a0-VV\u00a0\u00bb)). De plus, un script support\/json-rsync-version a \u00e9t\u00e9 ajout\u00e9, permettant de g\u00e9n\u00e9rer une sortie JSON similaire bas\u00e9e sur les informations fournies en texte lors de l'indication simple de l'option \u00ab\u00a0\u2014version\u00a0\u00bb (pour la compatibilit\u00e9 avec les versions ant\u00e9rieures de rsync).\n
La configuration \u00ab\u00a0use chroot\u00a0\u00bb dans rsyncd.conf, qui r\u00e9gule l'utilisation de l'appel chroot pour une isolation suppl\u00e9mentaire du processus, est par d\u00e9faut d\u00e9finie sur \u00ab\u00a0unset\u00a0\u00bb, ce qui permet d'utiliser chroot en fonction de sa disponibilit\u00e9 (par exemple, l'activer lorsque rsync est ex\u00e9cut\u00e9 avec des droits root et ne pas l'activer lorsqu'il est ex\u00e9cut\u00e9 par un utilisateur non privil\u00e9gi\u00e9).\n
La performance de l'algorithme de recherche de fichiers de base pour les fichiers cibles manquants, utilis\u00e9e avec l'option \u00ab\u00a0\u2014fuzzy\u00a0\u00bb, a \u00e9t\u00e9 augment\u00e9e d'environ deux fois.\n
La repr\u00e9sentation du temps dans le protocole, utilis\u00e9e lors de l'interaction avec les anciennes versions de Rsync (avant la branche 3.0), a \u00e9t\u00e9 modifi\u00e9e\u00a0: le temps epoch de 4 octets est alors trait\u00e9 comme \u00ab\u00a0unsigned int\u00a0\u00bb, ce qui emp\u00eache de transmettre le temps avant 1970, mais r\u00e9sout le probl\u00e8me de la sp\u00e9cification du temps apr\u00e8s 2038.\n
L'absence de chemin cible lors de l'appel du client rsync est d\u00e9sormais consid\u00e9r\u00e9e comme une erreur. Pour restituer le comportement ancien o\u00f9 un chemin vide \u00e9tait interpr\u00e9t\u00e9 comme \u00ab\u00a0.\u00a0\u00bb, l'option \u00ab\u00a0\u2014old-args\u00a0\u00bb a \u00e9t\u00e9 propos\u00e9e. <\/ul>\n
On peut \u00e9galement noter la publication de la version de l'outil rclone 1.60, qui est un \u00e9quivalent de rsync destin\u00e9 \u00e0 copier et synchroniser des donn\u00e9es entre un syst\u00e8me local et divers stockage cloud tels que Google Drive, Amazon Drive, S3, Dropbox, Backblaze B2, OneDrive, Swift, Hubic, Cloudfiles, Google Cloud Storage, Mail.ru Cloud et Yandex.Disk. Le code du projet est \u00e9crit en Go et est distribu\u00e9 sous la licence MIT. <\/p>\n
Dans cette nouvelle version : des backends pour le stockage de sauvegardes dans les entrep\u00f4ts Oracle object storage et SMB\/CIFS ont \u00e9t\u00e9 ajout\u00e9s. Le backend de stockage S3 prend en charge la gestion des versions et a ajout\u00e9 la possibilit\u00e9 de travailler avec les fournisseurs IONOS Cloud Storage et Qiniu KODO. Le backend local int\u00e8gre la possibilit\u00e9 d'ajouter des filtres pour ignorer les erreurs li\u00e9es aux droits d'acc\u00e8s. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"