Time Backup A

[thetrooper45]

Bonjour à tous,

Depuis maintenant 2,3 jours, je reçois des notifications par e-mail qui me disent :

Cher utilisateur,

Time Backup sur serveur-syn a échoué. Veuillez vérifier le journal du programme pour de plus amples informations.

Tâche : communs auto

Version : 20120213-1030

Destination : usbshare1

Je ne comprends pas car il reste plus de la moitié de l'espace sur l'usbshare1 (disque dur externe), j'y ai accès en lecture et en écriture, donc le souci ne vient certainement pas du disque externe.

Je suis donc obligé de faire des sauvegardes manuelles mais bon, j'aimerais que ça se fasse automatiquement comme d'habitude.

Je suis allé dans time Backup -> Liste des tâches et là, tout y est et correctement paramétré...

Modèle : DS 710+

Version DSM :3.2-1955

Merci d'avance

[PatrickH]

As tu activé l’hibernation sur ton disque USB externe ? si oui essaye de l'enlever pour voir si le problème persiste !

Patrick

[thetrooper45]

J'ai désactivé l'hibernation via le menu d'alimentation, j'ai débranché/rebranché le disque dur et relancé l'interface web. Il est bien reconnu dans les périphériques externes mais pas dans le navigateur de fichiers(plus de usbshare1 sur lequel le backup s'effectuait). J'ai toujours les alertes e-mail comme quoi le backup a échoué.

Modifié le 13 février 2012 par thetrooper45

[thetrooper45]

Après un redémarrage du synology, le disque dur est revenu dans l'arborescence mais les backups ne se font toujours pas.. Après consultation dans les journaux de Time backup, il m'indique [Nom_du_backup] has failed to backup version [Numéro_de_version] due to [failure to create snapshot]

J'ai vu sur les forums qu'il s'agissait d'un problème d'écriture par rapport au disque dur externe, faut-il que je le reformate en ext4 ou y a-t-il une autre solution moins radicale ?

edit : J'ai testé la sauvegarde traditionnelle via le dsm également et cela fonctionne...

Help please, merci!

Modifié le 15 février 2012 par thetrooper45

[CoolRaoul]

J'ai le meme problème depuis que j'ai décidé de tester time backup sur un répertoire ce week-end.

Ca se passe bien pendant quelques passes et soudain ça coince avec ce genre d'erreur (dans la syslog)

BK_WARN:Another backup is still in process, abort

Me demande si c'est bien fiable ce mécanisme ...

EDIT:

Trouvé l'explication de ce problème spécifique, suite a une fausse manip j'avais deux cron qui tournaient en parallèle et les tous les jobs étaient donc exécutés deux fois simultanément, parmi lesquels celui de time backup.

Ceci dit je retrouve a nouveau les problèmes comme ceux décrit plus haut, à savoir " [failure to create snapshot]"

Modifié le 27 février 2012 par CoolRaoul

[pierretro]

Bonjour,

J'ai le même problème. Pouvez-vous m'indiquer ou se trouve le journal de Time Backup?

merci

[CoolRaoul]

Ca à recommencé chez moi ... et ça commence à me les briser

Pour le journal centre de paquets->time backup->"plus"->journal

[pierretro]

Merci

A présent j'ai un autre problème, avec Mail Station. Je peux recevoir des mails, mais pas en envoyer.

(Undelivered Mail Returned to Sender).

Ou faut-il chercher?

[CoolRaoul]

Merci

A présent j'ai un autre problème, avec Mail Station. Je peux recevoir des mails, mais pas en envoyer.

(Undelivered Mail Returned to Sender).

Ou faut-il chercher?

Déjà commencer par poster dans le bon forum

[CoolRaoul]

Ca à recommencé chez moi ... et ça commence à me les briser

Je pense avoir trouvé la cause du problème! (sur ma config en tout cas)

Faut d'abord savoir que timebackup utilise la crontab pour mettre en place son "scheduling"

La commande qu'il insère dans la contab est

/usr/syno/bin/timebkp create_version --unique <N>

ou <N> est le numéro de tache time backup (peut se retrouver avec la commande "timebkp list_task --name=<nom tache>") Lorsque mes sauvegardes time backup commençaient à foirer , j'avais constaté que l'éxécution manuelle de cette commande reussissait bien à effectuer le snapshot. Par contre les sauvegardes programmées continuaient à planter ("failed to create snapshot") et je n'avais pas trouvé d'autre solution que le reboot. C'est alors que j'ai réalisé qu'il m'arrivait parfois de relancer crond pour qu'il prennent en compte des modifications personnelles de /etc/crontab. Je procédais simplement comme ceci:

/usr/syno/etc.defaults/rc.d/S04crond.sh stop

/usr/syno/etc.defaults/rc.d/S04crond.sh start[/code]




Mais ceci à pour effet de faire hériter à crond (et à toute les jobs  qu'il lance) une copie de l'environnement courant du shell.

On peut le constater aisément comme suit:

[code]ps ex | grep crond[/code]

(si on a installé le ps "optware" par "ipkg install procps") J'ai donc essayé de m'astreindre à relancer cron avec un environnement vierge; de cette façon:

[code]env - /usr/syno/etc.defaults/rc.d/S04crond.sh start[/code]

Et, jusqu'ici, tout fonctionne sans erreur (je croise les doigts)

Modifié le 9 avril 2012 par CoolRaoul

[CoolRaoul]

J'ai donc essayé de m'astreindre à relancer cron avec un environnement vierge; de cette façon:

env - /usr/syno/etc.defaults/rc.d/S04crond.sh start

Et, jusqu'ici, tout fonctionne sans erreur (je croise les doigts)

Bon, je viens de m'apercevoir qu'avec la dernière update DSM, si on applique la meme approche au serveur apache systeme ("/usr/syno/etc/rc.d/S97apache-sys.sh"), timebackup refuse de créer des versions via l'interface WEB. J'ai trouvé un compromis qui semble fonctionner dans tous les cas: en mettant uniquement les variables suivantes dans l'environnement des services lorsque je les redémarre à la main:

• PATH
• USER
• SHELL
• HOME

Ce qui donne le script suivant de redémarrage de service:

#! /bin/sh


PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin

cd /tmp


svcdir="/usr/syno/etc/rc.d"

svcname="$1"

command="$2"

if [ "$svcname" = "" ] ; then

	echo "Usage: $0 <service> [stop|start|status|restart]"

	echo "Services:"

	ls -1 $svcdir/S[0-9][0-9]*.sh | sed -e 's@^.*/@@' -e 's/^S../	/' -e 's/\.sh$//' | sort

	exit 1

fi >&2



for f in $svcdir/S[0-9][0-9]$svcname.sh

do

	env -  PATH=$PATH USER=root SHELL="/bin/sh" HOME=/  $f $command

done


[/code]

Modifié le 19 avril 2012 par CoolRaoul

[RRefoxy]

Bjr,

Je prends connaissance du sujet car j'ai aussi le même probleme. A part cette solution de modifier le script ou de faire une sauvegarde manuelle...

Est-ce une info à faire remonter chez Syno pour une prochaine mise à jour du DSM.