Internal backup from on share folder to an other is not working
it seems the internal_backup commande is set to timeout afin 30s … which is not suffisent to backup my photos dir with 121444
(command internally use : rsync --timeout=30 )
Welcome to the Community.
This is by means of RSync? Have you had any luck or clue related to what the issue is in one of the RSync threads?
i reformulate
i try to do interal backup some share dir but it doesn t success…
i ve made a connection with ssh to see wich command is lunch and param … and internal_backup script use rsync to make backup.
The rsync command is use with many parameters and it has timeout=30, which means the command has to end in 30second.
Could you (western digital) patch your backup command to suppress this stupid timeout or make it configurable.
Trancer wrote:
Welcome to the Community.
This is by means of RSync? Have you had any luck or clue related to what the issue is in one of the RSync threads?
It’s the same issue as mentioned in this “feature” request http://community.wd.com/t5/Personal-Cloud-Ideas/Please-add-vatiable-Timeout-value-for-usb-backup-rsync-in/idi-p/828403 and it’s been affecting me, too.
internal_backup (or, in that case, any storage backup process with rsync as the backend) launches rsync on a hard-linked copy (if the backup’s incremental) of the backup destination directory.
But rsync has to scan the source and target directory prior to running the sync itself - and that scan fails on large directories because of the timeout mentioned in the issue:
du: write error
dry_total_size:2
rsync: writefd_unbuffered failed to write 686 bytes to socket [sender]: Broken pipe (32)
rsync error: timeout in data send/receive (code 30) at io.c(1530) [sender=3.0.7]
This does not happen on the initial backup, becuase that’s just a plain copy - it only happens on a second and any subsequent runs of a backup of a large (in terms of structure) directory.
EDIT: I forgot to add that this is not solely My Cloud Mirror issue, as I’m experiencing it on the EX4, too.
