Timebackup "mange" 2,4 Go Toutes Les Heures

[SAMU]

Ce post est autour de TimeBackup et de l'espace occupé.

Pas du tout le temps de répondre en détails à ces interrogations. Il faut que tu t'informes sur:
- Sauvegarde par image disque.
- Sauvegarde simple (tous ou une partie des fichiers)
- Sauvegarde incrémentale (seuls fichiers modifiés) (ce que fait, TimeBackup mais en plus il crée des liens vers ceux non modifiés, les hard links)
Ce sera d'avantage sur un site sur les sauvegardes, en général, que tu trouveras les infos basiques, moins sur un site sur les SYNO, plutôt pro.
Attention, mon expérience m'amène à penser que beaucoup de softs de sauvegarde ne sauvegardent pas tout. C'est la raison première pour laquelle j'avais développé autour de Robocopy (voir plus haut).

Si tu as des questions précises (et des observations) sur TimeBackup et de l'espace occupé, reviens les formuler ici.

Bonne chance,

P.S. Cygnus, regarde du coté de "Synology Data Replicator 3" qui pourrait correspondre à ta recherche.

Modifié le 2 février 2014 par SAMU

[Cygnus]

Je comprends, merci

[guigeek]

Bonjour,

J'ai un problème similaire à vous.

J'avais plusieurs centaines de Go de fichiers (essentiellement des photos et des videos de famille) que je synchronisais via la synchronisation de dosiers entre deux syno (DS412+ et DS410j) via internet, dans un but de sauvegarde.

Souhaitant avoir un historique de modification, j'ai changé mon fisil d'épaule et suis passé sur un Time Backup de depuis le DS412+ vers le DS410j, toujours via internet. J'ai ajouté les répertoires un par un pour qu'ils se synchronisent par petit bout, mais depuis quelques jours, j'ai le message : "Time Backup sur DiskStation est terminée, mais certains partages ont été ignorés."

Par ailleurs, TimeBackup prends beaucoup beaucoup de place sur la destination, comme ce que vous exprimez dans vos posts. (évidemment, je suis en mode "déverouillé")

Ma première priorité est de faire en sorte que ca marche et que TimeBackup aille jusqu'au bout. Ma seconde sera de comprendre pourquoi ca prends autant de place.

Donc pour avancer sur le premier point :

Au vus de cette conversation j'ai lancé via batch une commande pour retiré l'attribut lecture seul de tous les fichiers.

Je m'aperçois que sur les 2 partages un contient effectivement des ACL microsoft... je vais voir vu qu'elles ne sont pas utilisées pour les desactivés et voir si cela aide à resoudre mon problème ...

Zorineau, pourrais tu me passer la commande batch pour retier l'attribut read-only ? je suis pas un expert en ligne de commande (et je m'en excuse, d'ailleurs)

D'autre part, je n'ai pas activé la gestion des droits via ACL, quelqu'un sait il s'il est possible qu'il y en ait quand même ?? et dans l'affirmative, comment le voir et les virer ?

Merci par avance pour vos lumières...

Long live Syno

[aegir_fr]

Un spécialiste de Linux aurait-il la réponse ?

En ext4, par défaut un inode occupe 256 octets.

Donc 10.000 fichiers occupent au minimum 2,5 Mo

Cependant un inode ne peut contenir que 100 octets d'extended attributes (comme typiquement les ACL de windows), donc si ce n'est pas suffisant il les stocke dans un block de données (qui fait en général 4Ko).

Dans ce cas là, chaque fichier occupe 256+4096=4352 octets.

Pour 10.000 fichiers cela fait 43 520 000 octets ; soit 41,5 MiO

Donc rien de surprenant dans ton cas.

[SAMU]

Merci Aegir_fr !

Désolé, je n'avais pas été averti de ta réponse. Je te remercie également d'autant de précision.

Comme Guigeek le propose, Zorineau, pourrais-tu nous communiquer une commande permettant de retirer les ACL Windows et de diminuer ainsi la taille des sauvegardes.

Pour info, je viens de faire des tests, avec la DSM 5 béta (TimeBackup 1.2-2359) sur le Syno cible:

ce sont les fichiers eux-mêmes qui sont intégralement recopiés (100 Go de fichiers -> 100 Go de pris à la nouvelle sauvegarde, même s'ils n'ont pas changés) !!!!!!!!!!!!!!!!!!

Modifié le 27 janvier 2014 par SAMU

[aegir_fr]

Comme Guigeek le propose, Zorineau, pourrais-tu nous communiquer une commande permettant de retirer les ACL Windows et de diminuer ainsi la taille des sauvegardes.

A priori, ça devrait être "getfacl fichier" pour voir les ACL d'un fichier ; et "setfacl -b fichier" pour enlever les ACL d'un fichier.

Mais je n'ai pas pas mon syno sous la main pour tester, et de toute façons, j'ai pas les ACL d'activés dessus.

ce sont les fichiers eux-mêmes qui sont intégralement recopiés (100 Go de fichiers -> 100 Go de pris à la nouvelle sauvegarde, même s'ils n'ont pas changés) !!!!!!!!!!!!!!!!!!

T'es sûr qu'ils n'ont réellement pas changé ? (droits d'accès, date de modification etc.)

Modifié le 27 janvier 2014 par aegir_fr

[SAMU]

Certain !

...et cela se produit, dès lors, à chaque nouvelle sauvegarde !

Modifié le 27 janvier 2014 par SAMU

[aegir_fr]

A priori, ça devrait être "getfacl fichier" pour voir les ACL d'un fichier ; et "setfacl -b fichier" pour enlever les ACL d'un fichier.

Mais je n'ai pas pas mon syno sous la main pour tester, et de toute façons, j'ai pas les ACL d'activés dessus.

Après vérification, il n'y a pas getfacl / setfacl installés sur mon syno.

Par contre, synology a apparemment fait son propre outil maison nommé "synoacltool".

"synoacltool -h" donne les options disponibles. Il semblerait qu'on puisse supprimer les acl avec la commande "synoacltool -del /mon/fichier"

À tester hein ? Comme je l'ai dit, j'ai pas les ACL activés sur mon syno, donc je peux pas tester.

À noter, l'outil a des options spécifiques, permettant par exemple d'effacer l'archive-bit d'un fichier. Voir la doc obtenue avec "-h".

[SAMU]

Merci Aegir_fr.

Pour ma part, je n'ai plus non plus d'ACL d'activé sur le Syno. Je les avais retirés après avoir découvert, après leur apparition, les problèmes qu'ils avaient créés (fichiers Word, TimeBackup déjà etc.).

Il me semble cependant (je ne sais plus ce qui m'avait alerté) que théoriquement absents, les ACL sont présents mais configurés au plus large.

Je vais essayer, dès que possible, de regarder du coté des utilitaires que tu évoques (bien que mes dernières approches de Linux datent de plusieurs années).

Modifié le 27 janvier 2014 par SAMU

[SAMU]

J'ai ouvert un sujet sur Time Backup qui me "mange" 100 Go à chaque sauvegarde sur le Syno cible sous DSM 5 beta:

Modifié le 31 janvier 2014 par SAMU

[vincent7778]

Juste pour savoir, comment sais-tu qu'il "mange" la place ? Comment mesures-tu cela ?

[SAMU]

Pas très précis, mais le plus simple, est d'utiliser le gestionnaire de stockage.

[vincent7778]

Ok, parce que d'après ce qu'on disait dans le calcul de taille de la sauvegarde par le Syno est parfois complètement fausse. Personnellement le TimeBackup se fait sur DD USB dédié, et donc par le gestionnaire de matériel, on peut voir l'espace réel occupé.

Tu n'as qu'à regarder la différence chez moi

[aegir_fr]

Pas très précis, mais le plus simple, est d'utiliser le gestionnaire de stockage.

Salut,

Pour savoir précisément l'occupation de ta sauvegarde, en étant dans le répertoire de la sauvegarde tu peux utiliser la commande :

find . -type f -links 1 -exec ls -lsa {} ; | awk '{SUM += $6} END {printf "%16.1f",SUM/1024; print " kilo-octets n" }'

Ça va faire la somme de la taille de tous les fichiers réguliers dont le compteur de hardlinks est à 1. Ça ne va donc pas compter les fichiers qui n'ont pas été modifiés depuis la dernière sauvegarde, et qui sont donc juste linkés.

Le résultat sera un peu différent de ce que t'indique le gestionnaire de stockage, car là on ne compte que la taille des données, on ne compte pas les éventuels extended-attributes (ACL). De plus on ne compte que les données "utiles" du fichier. Par exemple un fichier de 200 octets sera comptabilisé par cette commande comme 200 octets, alors que pour le gestionnaire de stockage, le fichier occupant 1 block de données, il va "manger" 4096 octets de place sur le disque (1 block).

Exemple :

nas> pwd

/volume2/backup/TimeBackup/nas_001132193CB1/task_1/20140126-0000

nas> find . -type f -links 1 -exec ls -lsa {} ; | awk '{SUM += $6} END {printf "%16.1f",SUM/1024; print " kilo-octets n" }'

8972085.9 kilo-octets

nas> du -sh .

86.8G .

Voilà, j'ai 86,8 Go de données sauvegardées, et ma sauvegarde de dimanche dernier n'occupe que 8,9 Go

(désolé pour la lisibilité, avec le awk busybox des synology, on ne peut pas utiliser le flag des séparateurs de milliers).

[SAMU]

Grand merci pour ta commande et tes explications (comme je l'avais dit plus haut je ne suis pas linuxien mais je vais essayer de décortiquer ta commande pour mieux la comprendre).

C'est assez fastidieux de faire un "CD /dossier" pour chaque répertoire de sauvegarde.
Abuserais-je en te demandant comment compléter ta commande pour qu'elle donne l'occupation, un à un, de chaque répertoire de sauvegarde, à la manière, sous DOS, de "for /D %X in (*) do TA_COMMANDE_pour_le_dossier_%X" ou "for /F %X in ('dir /b /ad) do TA_COMMANDE_pour_le_dossier_%X"

P.S.

En tout cas, pour l'instant, en utilisant ta commande, je retrouve globalement les observations que j'avais faites en me basant sur le gestionnaire de stockage.

Modifié le 31 janvier 2014 par SAMU

[aegir_fr]

tu peux faire ça :

nas> pwd
/volume2/backup/TimeBackup/nas_001132193CB1/task_1
nas> ls
20131215-1810 20131229-0000 20140105-0000 20140112-0000 20140119-0000 20140126-0000
nas> for i in * ; do echo $i ; find $i -type f -links 1 -exec ls -lsa {} ; | awk '{SUM += $6} END {printf "%16.1f",SUM/1024; print " kilo-octets n" }' ; done

20131215-1810
14675.6 kilo-octets

20131229-0000
0.0 kilo-octets

20140105-0000
0.0 kilo-octets

20140112-0000
0.0 kilo-octets

20140119-0000
0.0 kilo-octets

20140126-0000
8972085.9 kilo-octets

Mais c'est pas très intéressant, parce que comme seuls les fichiers avec le hardlink à 1 sont comptés, ça ne donne pas des résultats pertinents.

Par exemple, pour la sauvegarde du 19 janvier, il est indiqué "0.0 kilo-octets" ; on pourrait croire qu'il n'y a pas eu de fichier modifié entre le 12 et le 19 janvier. Mais c'est pas vrai, si un fichier a été modifié mettons le 18 janvier, et n'a pas été modifié ensuite il figure dans les sauvegardes du 19 et 26 janvier, il a donc son hardlink à 2.

Cette commande n'est donc utile qu'en l'appliquant sur la sauvegarde la plus récente pour voir le delta entre les 2 dernières sauvegardes.

Modifié le 31 janvier 2014 par aegir_fr

[SAMU]

En effet !

Je suis étonné qu'il n'existe pas de commande Linux permettant de ne lister que les fichiers (sans les hardlinks) ou que les hardlinks (sans les fichiers) (sous DOS: dir /a-L et dir /aL).

Elle semble pourtant exister intrinsèquement, puisque "ls -l" devrait normalement afficher un renvoi, en fin de ligne, pour les hardlinks:

"lrwxrwxrwx 1 root root 31 mar 24 08:05 nom_hardlink - > nom_ficher_réel".

Avec DSM (sous SSH ou Telnet), je ne retrouve pas ce renvoi (qu'il aurait suffi de vérifier pour ne pas comptabiliser l'espace indiqué en regard des hardlinks).

Modifié le 31 janvier 2014 par SAMU

[aegir_fr]

Non, tu confonds les hardlinks et les liens symboliques.

Les hardlinks sont des fichiers normaux.

En fait, n'importe quel fichier est un hardlink ; sauf qu'à sa création le compteur de hardlinks est à 1.

2 hardlinks ont forcément le même noms, puisque c'est le même inode. Edit Non là je ne suis pas clair, 2 hardlinks peuvent avoir des noms différents, mais comme c'est le même inode de fichier il n'y en a pas un qui pointe sur l'autre. On peut supprimer le 1er le 2ème sera toujours là et vice-versa. Le fichier ne sera supprimé du disque que lorsque le compteur de hardlinks de l'inode arrivera à zéro.

Sous DOS/Windows les hardlinks n'existent pas, il n'existe que l'équivalent des liens symboliques.

Autrement on peut scripter un truc basé sur les inodes pour chercher les différences.

Modifié le 31 janvier 2014 par aegir_fr

[SAMU]

Non, non ! Il y a bien des hardlinks sous NTFS (nommés aussi Liens Réels chez MicroSoft).

Pour ce qui est des commandes que je t'ai citées, tout à l'heure, en effet, elles ne sont capables que de repérer les lien symboliques et les joncions.

La commande DOS pour créer un hardlink est: MKLINK /H Lien Cible

- Mklink (tout court) Lien Cible -> crée un lien symbolique vers un fichier

- Mklink /D Lien Cible -> crée un lien symbolique vers un Dossier

- Mklink /J Lien Cible -> crée une jonction

voir: http://fspsa.free.fr/jonctions.htm#hardlinks.reg

Pour en revenir à Linux, il me semblait que normalement lorsque "ls -l" liste des fichiers, il affiche à droite, et pour les seuls hardlinks, une référence au fichier vers lequel pointe le hardlink.

Est-ce que je me trompe ?

Modifié le 31 janvier 2014 par SAMU

[aegir_fr]

Mais oui, tu te trompes, je te dis que tu confonds avec les liens symboliques.

Je ne sais pas comment l'expliquer autrement, mais dans un hardlink il n'y a pas de "fichier vers lequel tu pointes". C'est juste un non-sens.

Par définition, tous les fichiers sont des hardlinks.

Je vais essayer d'expliquer simplement :

Un "fichier" c'est un i-node ( une sorte de bloc ) qui contient les caractéristiques du fichier : propriétaire, droits d'accès, taille, liste des blocs de données etc. et aussi le compteur de hardlinks. Mais l'i-node ne contient _PAS_ le nom du fichier.

Tant que ce compteur de hardlinks est à zéro, le fichier n'existe pas sur le filesystem.

Ensuite, on donne un nom au fichier, pour ça on ajoute dans le répertoire où on veut mettre le fichier une entrée, avec le nom et le numéro d'inode du fichier. En faisant cela on incrémente le compteur de hardlinks de l'inode.

À ce moment, le fichier existe enfin. Il a une entrée dans un répertoire (donc un nom) et le compteur de hardlinks est supérieur à zéro.

Si on ajoute d'autres entrées dans ce répertoire (ou d'autres répertoires) pointant vers ce même i-node, pour chaque entrée le compteur de hardlinks de l'inode est incrémenté.

Ensuite, si on détruit une entrée dans un répertoire qui pointe sur cet inode, le compteur de hardlinks est décrémenté. Lorsque le compteur arrive à zéro, le filesystem efface l'inode et libère les blocs de données.

Il n'y a donc pas de notion de "pointer vers un fichier". Chaque fichier est un hardlink vers un inode.

Sous Un*x ; un fichier n'est pas désigné par son nom, mais par son numéro d'inode (c'est d'ailleurs le seul moyen de supprimer un fichier qui a dans son nom des caractères invalides). Ça fait plus de 30 ans que ça fonctionne comme ça.

Modifié le 31 janvier 2014 par aegir_fr

[SAMU]

Je suis tout à fait d'accord. On peut dire que chaque lien pointe vers la même adresse data en mémoire disque.

Ce que l'on nomme communément LE fichier n'est en fait qu'un lien vers ces datas, au même titre que n'importe quel autre suplémentaire que l'on nommera alors "hardlink".

Le hardlink n'est rien d'autre que la reproduction du 1er lien (improprement appelé LE fichier). Cette nouvelle entrée peut avoir un nom différent mais à l'instar de toute entrée du système de fichier, ne peut être que sur la même partition que les datas auxquelles il renvoie.

En effet ma formulation était impropre quand je disais qu'un hardlink pointait vers le 1er fichier.

Une fois dédoublée la 1ère entrée, il ne devient plus possible d'identifier laquelle est à la base du fichier d'origine, à moins de comparer leurs dates de création par l'intermédiaire de celle du répertoire de sauvegarde.

[aegir_fr]

Une fois dédoublée la 1ère entrée, il ne devient plus possible d'identifier laquelle est à la base du fichier d'origine, à moins de comparer leurs dates de création par l'intermédiaire de celle du répertoire de sauvegarde.

Non même pas ! La date de création figure dans l'inode ; quel que soit le hardlink pointant vers l'i-node ils auront tous la même date, le même propriétaire, les mêmes droits etc. puisque c'est le même fichier.

Par contre, tu peux effectivement comparer la date de création par rapport à la date de la sauvegarde n-1

Modifié le 31 janvier 2014 par aegir_fr

[aegir_fr]

Bon, j'ai continué à fouiller, et manifestement voici un cas qui peut expliquer des problèmes :

nas> ls -lsa "20140119-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat"
4 -rwxrwxrwx 5 patricia parents 1588 Mar 17 2013 20140119-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat
nas> ls -lsa "20140126-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat"
4 -rwxr-x--- 1 patricia parents 1588 Mar 17 2013 20140126-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat
nas> synoacltool -get "20140119-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat"
(synoacltool.c, 350)It's Linux mode
nas> diff "20140126-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat"
"20140119-0000/homes/patricia/PATRICIA-2012/Backup Set 2013-03-03 190610/Backup Files 2013-03-17 190003/Catalogs/Backup files 4.wbcat"
nas>

J'ai donc bien 2 fichiers parfaitement identiques, dont la date n'a pas été modifiée entre mes 2 derniers backups, et pourtant comme on peut le voir, au backup précédent il y avait 5 hardlinks, alors qu'au dernier backup il a recréé le fichier avec un hardlink à 1.

Et les ACL ne sont pas activés sur mon syno (et ne l'ont jamais été).

En fait, la différence ce sont les droits d'accès de base (owner, group, other).

Et effectivement, entre les 2 backups, j'ai fait des modifs sur les privilèges des utilisateurs.

Donc toute modif sur les privilèges des utilisateurs peut entraîner un backup différentiel d'un très grand volume.

Modifié le 31 janvier 2014 par aegir_fr

[SAMU]

Ta trouvaille est vraiment intéressante.

De mon coté, je viens de trouver un autre problème, lorsqu'une sauvegarde a été conservée partiellement (après plantage de la connexion).

Il apparait que tout ce qui n'avait pas pu être hardlinké est retransféré à la prochaine sauvegarde comme s'il n'avait jamais existé.

C'est vraiment une grosse faiblesse de TimeBackup en réseau.

J'avais noté, lors de tests, qu'après plantage de connexion TimeBackup continuait de tourner un certain temps et que, s'il pouvait se reconnecter, il annulait le répertoire de la sauvegarde déjà entamée. Passé ce délai, le répertoire subsiste.

Il sera intéressant d'observer ce qui se passe lors d'un changement d'IP publique (connexion par DDNS). Après plantage du backup, par la perte de l'IP, annule-t'il le répertoire entamé, après avoir retenté une nouvelle connexion via DDNS ?

Grace à ta commande "magique" (en tout cas pour un non-linuxien), j'envisage de pouvoir supprimer les sauvegardes inutiles, composées uniquement de hardlinks >1 (en remontant de la sauvegarde la plus ancienne à la dernière).

En effet, une limitation de TimeBacup qui m'énerve, c'est celle du nombre de jeu de sauvegarde possible qui m'a contraint à utiliser "Smart Recycle" (il y a 1 sauvegarde/heure).

De plus je vais aussi pouvoir retirer les hardlinks, qui, pour moi, nuisent à la recherche des versions de fichiers.

Modifié le 1 février 2014 par SAMU

[aegir_fr]

Grace à ta commande "magique" (en tout cas pour un non-linuxien), j'envisage de pouvoir supprimer les sauvegardes inutiles, composées uniquement de hardlinks >1 (en remontant de la sauvegarde la plus ancienne à la dernière).

Attention hein ? Il faut supprimer les sauvegardes une par une ; et ré-exécuter la commande après chaque suppression. (puisque à chaque suppression, tous les compteurs de hardlinks seront décrémentés).