bbeto Posté(e) le 11 septembre 2019 Partager Posté(e) le 11 septembre 2019 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. Le journal ne m'apporte pas beaucoup d'informations... (Exception occured while backing up data.) 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). 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 More sharing options...
.Shad. Posté(e) le 11 septembre 2019 Partager Posté(e) le 11 septembre 2019 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 More sharing options...
bbeto Posté(e) le 11 septembre 2019 Auteur Partager Posté(e) le 11 septembre 2019 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 More sharing options...
bbeto Posté(e) le 11 septembre 2019 Auteur Partager Posté(e) le 11 septembre 2019 Bon, un test avec un autre HDD a fonctionné (plusieurs tests de différentes sauvegardes). Ca me met pas trop en confiance, mais à voir avec le temps. Merci en tout cas pour ton aide @shadowking! Lien vers le commentaire Partager sur d’autres sites More sharing options...
.Shad. Posté(e) le 11 septembre 2019 Partager Posté(e) le 11 septembre 2019 Pour les logs je ne connais pas suffisamment le protocole de sauvegarde malheureusement pour t'aiguiller. Tiens-nous au courant, et vois ptet avec le support de Synology. Lien vers le commentaire Partager sur d’autres sites More sharing options...
bbeto Posté(e) le 27 septembre 2019 Auteur Partager Posté(e) le 27 septembre 2019 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 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 More sharing options...
.Shad. Posté(e) le 27 septembre 2019 Partager Posté(e) le 27 septembre 2019 Merci de ton retour, je vais voir ce que ça donne sur mon disque. Lien vers le commentaire Partager sur d’autres sites More sharing options...
Messages recommandés
Archivé
Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.