Aller au contenu

Echec de sauvegarde - problème de droits ?


bbeto

Messages recommandés

Bonjour,

Je rencontre un problème avec Hyper Backup. Depuis la dernière mise à jour, les sauvegardes vers un HDD externe en USB sont en échec.

hb.png.e34c6b600e22f29ab81777d1ef906d65.png


Le journal ne m'apporte pas beaucoup d'informations... (Exception occured while backing up data.)

journal.png.ff87ed6b24cc96fbf823c62bf7617ea2.png

J'ai testé avec plusieurs disques externes, réinstallé Hyper Backup, mais c'est la même chose.

J'ai remarqué que le propriétaire de la sauvegarde était 'admin', ce qui est étrange car j'ai désactivé cet utilisateur et créé un autre utilisateur admin (nommé autrement) que j'utilise pour lancer la tâche de sauvegarde.
Les droits sur le support USB et la sauvegarde dessus sont également affectés à 'admin' (avec le groupe 'users'). J'ai voulu changer ces droits pour y mettre l'utilisateur que j'utilise, mais impossible... (que ce soit en passant par File Station, ou en me connectant en ssh).

ssh.png.dfaeba4e701319bb8dbc2be9dde1a2ea.png

Versions installées :
Hyper Backup 2.2.1-1110
DSM 6.2.2-24922-3

Quelqu'un aurait déjà rencontré ce problème ? Auriez-vous des pistes à me suggérer ? Je suis à court d'idées...

Lien vers le commentaire
Partager sur d’autres sites

J'ai eu le même problème il y a quelques mois, il faut que tu te connectes en ssh et que tu affiches le contenu des logs

cat /var/log/messages

Tu auras beaucoup plus d'infos ici.
Par contre, je ne vuex pas te donner de faux espoirs, malgré un mois et demi de contact avec le support Synology, on n'a jamais trouvé d'où venait le problème.
Chose étrange, ça ne se produisait que sur l'un de mes deux dd externes qui servent de destination de sauvegarde.

Le vieux dd de 500go datant d'il y a 4-5 ans n'a jamais eu le moindre problème, un récent de 2 To, au bout de quelques incrémentations de sauvegarde j'ai la même erreur que toi sur Hyperbackup, obligé de supprimer la sauvegarde et de recommencer une complète.
Et les deux tâches sauvegardent rigoureusement les mêmes données.

Ce que je n'ai pas encore essayé, changer le câble USB du disque de 2 To.
Cela dit, je me sers du dd de 2 To pour d'autres choses, et je n'ai jamais rencontré le moindre problème d'erreur de transfert ou de perte de données...

Bref vis ma vie 😄 regarde déjà les logs et poste les ici.

Lien vers le commentaire
Partager sur d’autres sites

Merci pour la réponse rapide ! Même si elle n'augure rien de bon.. argh

Voici les logs lorsque je lance la tâche de sauvegarde :

Citation

2019-09-11T11:10:56+02:00 <NasName> img_backup: [2135]img_backup.cpp:2375 Local Backup Task has been started: task_ID: 10
2019-09-11T11:10:56+02:00 <NasName> img_backup: [2135]img_backup.cpp:1757 Action: [local backup], Repo Path: [usbshare1], LinkKey: [<NasName>_0011329AD6AB_10], Cloud backup: [0], Target ID: [test.hbk], task ID: [10]
2019-09-11T11:10:56+02:00 <NasName> img_backup: [2135]img_backup.cpp:1759 app config Path: [/volume1/@tmp/BKP_APP_ei4gjH]
2019-09-11T11:10:56+02:00 <NasName> img_backup: [2135]img_backup.cpp:1761 data Path: [/<FolderToSavePath>], type: [0]
2019-09-11T11:10:57+02:00 <NasName> img_backup: (2135) [info] snapshot.cpp:328 take share [<SharedFolder>] backup snapshot [/volume1/@sharesnap/<SharedFolder>/GMT+02-2019.09.11-11.10.56]
2019-09-11T11:10:58+02:00 <NasName> img_backup: [2135]target.cpp:2501 Target test.hbk:2 needs roll-back
2019-09-11T11:10:58+02:00 <NasName> synoimgbkptool: [2204]target_roll_back.cpp:1323 [INFO] start moving buckets
2019-09-11T11:10:58+02:00 <NasName> synoimgbkptool: [2204]target_roll_back.cpp:1341 [INFO] finish moving buckets
2019-09-11T11:10:58+02:00 <NasName> synoimgbkptool: [2204]file_pool.cpp:268 [INFO] start moving files in file_pool
2019-09-11T11:10:58+02:00 <NasName> synoimgbkptool: [2204]file_pool.cpp:319 [INFO] finish moving files in file_pool
2019-09-11T11:10:59+02:00 <NasName> synoimgbkptool: [2204]target_roll_back.cpp:807 /volumeUSB1/usbshare:test.hbk roll-back done!!(err: 0)
2019-09-11T11:11:03+02:00 <NasName> synoimgbkp_tagmgr: [2260]tag_db.cpp:1103 info: last version tag db [/volume1/@img_bkp_cache/ClientCache_image_image_local.LAU8G2/last_version_tagdb] not exists [No such file or directory]
2019-09-11T11:11:03+02:00 <NasName> synoimgbkp_tagmgr: [2260]tag_db.cpp:1124 current version tag db [/volume1/@img_bkp_cache/ClientCache_image_image_local.LAU8G2/current_version_tagdb] already exists, remove it. parent_pid:[2135]
2019-09-11T11:11:06+02:00 <NasName> img_backup: (2135) backup_controller.cpp:3552 [BkpCtrl] All workers flush done, continue:(4)
2019-09-11T11:11:10+02:00 <NasName> img_backup: (2135) version_file_log.cpp:76 failed to link [/volumeUSB1/usbshare/test.hbk/Versionlog/log_3] to [/volumeUSB1/usbshare/test.hbk/Versionlog/log_3_2019-09-11_111057.csv], errno=[Operation not permitted]
2019-09-11T11:11:10+02:00 <NasName> img_backup: (2135) version_file_log.cpp:543 [version_file_log] failed to zip file [/volumeUSB1/usbshare/test.hbk/Versionlog/log_3], err:[Operation not permitted]
2019-09-11T11:11:10+02:00 <NasName> img_backup: [2135]version.cpp:2017 Warning: failed to perserve version log for /volumeUSB1/usbshare:test.hbk:3
2019-09-11T11:11:10+02:00 <NasName> img_backup: (2135) server_helper.cpp:1226 server version.VersionComplete() failed: [/volumeUSB1/usbshare/test.hbk/3], err from Version:[0]
2019-09-11T11:11:10+02:00 <NasName> img_backup: (2135) local_backup_controller.cpp:623 failed to do version complete: [0]
2019-09-11T11:11:10+02:00 <NasName> img_backup: (2135) local_backup_controller.cpp:58 failed to send backup-end request to server
2019-09-11T11:11:10+02:00 <NasName> img_backup: (2135) local_backup_controller.cpp:64 [BkpCtrl] error occurs: blRet[0], err(ST_UNKNOWN)
2019-09-11T11:11:10+02:00 <NasName> img_backup: (2135) backup_controller.cpp:3008 [BkpCtrl] failed to backup end, just return
2019-09-11T11:11:10+02:00 <NasName> img_backup: (2135) service_wrapper.cpp:79 failed to start backup service
2019-09-11T11:11:10+02:00 <NasName> img_backup: [2135]img_backup.cpp:1868 Failed to start backup task errno:1
2019-09-11T11:11:11+02:00 <NasName> img_backup: (2135) [info] snapshot.cpp:172 remove share [<SharedFolder>] backup snapshot [GMT+02-2019.09.11-11.10.56]
2019-09-11T11:11:11+02:00 <NasName> img_backup: [2135]img_backup.cpp:2435 failed to start task
2019-09-11T11:11:11+02:00 <NasName> img_backup: (2135) [err] backup_progress.cpp:466 Backup task [test] completes with result [3]. Time spent: [15 sec].
2019-09-11T11:11:11+02:00 <NasName> img_backup: (2135) [err] backup_progress.cpp:481 Total Size(Bytes):[31744], Modified Size(Bytes):[31744], Total Directory:[0], Modified Directory:[0], Total File:[1], Modified File:[1],
2019-09-11T11:11:11+02:00 <NasName> img_backup: [2135]img_backup.cpp:2173 Storage Statistics: TargetSize(KB):[0], LastBackupTargetSize(KB):[0], SourceSize(KB):[0], TotalFile:[0], ModifyFile:[0], NewFile:[0], UnchangeFile:[0], RemoveFile:[0], RenameFile:[0], RenameLogicSize(Bytes):[0], CopyFile:[0], CopyLogicSize(Bytes):[0], CopyMissFile:[0], CopyMissFileLogicSize(Bytes):[0]

A noter que même en recommençant une sauvegarde complète, j'ai toujours le problème... Je vais tenter un peu plus tard avec un autre HDD.

Lien vers le commentaire
Partager sur d’autres sites

  • 3 semaines après...

Mon retour d'expérience après avoir contacté le support Synology et effectué de multiples tests de mon côté.

Première chose : l'échec des backups est causé par l'activation de l'option de journal détaillé.

option_journal.png.c559419dd5cd0f43d4c2e2590d0066e9.png

Option activée --> échec
Option désactivée --> OK

Selon le support :

Citation

Après avoir consulté l'équipe de développement, il a été confirmé qu'il s'agit d'un problème connu qui sera corrigé dans Hyper Backup version 2.2.3.
Comme solution de contournement, évitez d'activer l'option "file change detail log" pour éviter l'échec de la sauvegarde et restez à l'écoute pour la mise à jour.

Deuxième chose : le propriétaire de la sauvegarde est 'admin' (alors que cet utilisateur est désactivé et n'est pas celui avec lequel je lance le backup)
Je n'ai pas eu d'explication en détails, mais le formatage du disque externe joue là-dessus.
Lorsque le disque est en FAT32 : l'utilisateur propriétaire est 'admin' et il est impossible de le changer
Lorsque le disque est en EXT4 : l'utilisateur propriétaire est '<utilisateur utilisé pour lancer la sauvegarde>' et il est possible de le changer

Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.