Timebackup "mange" 2,4 Go Toutes Les Heures

[SAMU]

Voici ma commande de suppression des hardlinks (pas encore testée):
for i in $(ls -d1 20??????-????/) ; do echo $i ; find $i -type f -links +1 -exec rm -f {} ; ; done
On ne devrait retrouver dans chaque sauvegarde que ce qui a changé dans la suivante.
Seule la plus récente devrait comporter l'ensemble des fichiers.

Modifié le 2 février 2014 par SAMU

[aegir_fr]

Oui ben vaut mieux tester...

Vu comme ça, je ne vois pas pourquoi ça ne marcherait pas, mais ça a un coté un peu "sauvage" et il y a souvent des cas de figure auxquels on avait pas pensé...

[MS_Totor]

salut,

sans interferer sur votre échange, que je trouve très interessant, je me permets de vous rappeler, quà moins de remplacer la busybox interne du syno par une version plus linux friendly, vous serez très limité.

j'ai du cross-compilé busybox comme tous les modules kernel/paquets necessaires à mon taff, pour pouvoir pleinement profiter des synos, même find était bridé en option, avec busybox à jour même ic2 etc... dispo pour du monitoring, et code plus ouvert.

je n'ai pas regardé le dépôt depuis pas mal de temps, mais cela me semble un paquet incourtable via ipkg.

++

[aegir_fr]

salut,

sans interferer sur votre échange, que je trouve très interessant, je me permets de vous rappeler, quà moins de remplacer la busybox interne du syno par une version plus linux friendly, vous serez très limité.

Oui mais c'est bon, le find -links +1 ça marche avec le find de la busybox. De même que les "while read" etc. ça marche bien avec /bin/ash.

Depuis le début de l'échange, le seul truc qui m'a manqué, c'est le flag ' du printf de awk pour avoir un séparateur de milliers.

Modifié le 3 février 2014 par aegir_fr

[SAMU]

Complément sur ce qui peut conduire à une nouvelle création de la totalité des fichiers:

- effacement du dernier répertoire de sauvegarde;

- changement de nom du dernier répertoire de sauvegarde;

- changement date/heure du dernier répertoire sauvegarde (TimeStamp contrôlé);

Modifié le 12 février 2014 par SAMU

[SAMU]

"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 "

Depuis l'update en DSM 5 et des TimeBackup affairants des synos source et cible cela ne semble plus poser de problème: la sauvegarde redémarre là où elle a été interrompue par le changement d'IP.

P.S. Sans que j'ai pu relever les conditions exactes, dans la version DSM 4.3 et TimeBackup affairant, des sauvegardes recommençant depuis le début étaient fréquentes après le changement d'IP

Modifié le 18 mars 2014 par SAMU