I have a 3TB MyBook attached to my 3TB MyCloud. The connection is supposed to be USB 3. However, I am getting about 23GB per hour transfer speeds and that seems about 100x too slow (640MB/s spec or 2TB/hr). Granted, Safepoints are designed to run in the background but I have intentionally eliminated any other traffic to the MyCloud. Since I had some other issues with the MyBook, I am concerned this still isn’t acting 100%.
Dear Stealth57, I own the same hardware except that I connected an external INTENSO USB3.0 Drive (4TB).
The good news of the Safepoint concept is that once the backup is done you can unplug the USB HDD and can
access it via any other PC. Reason: The directory structur is copied one by one to the external drive (no proprietary file extension).
The bad news is that the transfer of data to the extenal drive is incredible slow.
I did the following tests:
540 GB of mostly fotos and videos should be transferred as a first time Safepoint onto the new external USB drive (formatted as NTFS).
Result: It took exactly 781min, i.e. 540 000 MByte/(781*60s) = 11,52 MB/s
This is quite far away from the specification of the external HDD: 75 MB/s write speed
As a rule of thumb for me: 1/4h per 10 GB, 2,5h per 100 GB and 1 day per 1TB
So it highly depends on the amount of date you generate per week or month to find a good compromise for the safepoint frequency. We only speak of the delta to be updated !
As a private user I would say the backup job should get done overnight for the subsequent delta-updates.
By the way: The main PC can be shut down whilst the backup is running.
What happens if you do not want to add any new files to your USB Backupdrive but just adapt the file structure?
For example: /
//WDMycloud/user/directory1 /directory2/directory3 /filename -> //WDMycloud/user/directory1/filname
In Windows it is a drag and drop action to move a bunch of directories including the files to a more suitable location in the directory path. If you do this for the files on the WDMyCloud this is completed in some minutes even if (in my case) 16000 files were affected.
But what happens if you update your safepoint ? In this case (this test is momentarily running) it seems to be as strenuous as the creation of the initial Safepoint…
Never change the directory structure on WDMyCloud (except add or delete), if you have a lot of files behind it.
added remark 20:11
Test 2 was completed earlier as expected! t= 19:40 - 12:47 = 413 min (only)
The affected files had a volume of 144 GByte. This means a average transfer rate of
144 000 MByte/(413*60s) = 5,8 MByte/s
As this is about half of the expected transferrate, the files are processed 2 times: read (slowly) from the USB drive and written (slowly) to the new location (although I am not completely sure whether this is the correct explanation).
I hope you can extract some usefull information from my tests.
Here some screenshots of the ongoing test:
I have a 4TB elements on the usb3 of a 3TB wdmycloud and noticed that the performace is about 4 to 5Mbs when creating a safepoint also that the web gui takes for ever to update. I could understand the web gui being slow if the safepoint was running at say 40MBs which is half the speed I get when I copy from my PC to a WDMC share.
From investigation Safepoint appears to to use rsync to copy the data which if you check the forum has numerous complaints of very poor rsync performance.
As the Element’s drive appears as a share on the WDMC when connected to the USB3 port I have taken to using freefilesync on my PC and copying from the WDMC to the Elements share and get about 24MBs.
I don’t know if Safepoint is deliberately throttling the backup on purpose so the WDCMC can be responsive but going by the web gui performance they are not throttling it enough!
SO WD how about fixing Safepoint (rsync) performance with the option to throttle the backup for those who need responsive access during the backup
I resorted to FreeFileSync as well as I am one of the many that cannot get Safepoint to finish under any circumstances. I even applied the “fix” of downgrading to v3.x firmware. Apparently, this is a major compaint given the massive number of complaints on this forum. Levell II and WD engineering have no solution.