![]() ![]() ![]() |
|
I just did a throughput test using scp between two Ubuntu 16.04 boxes (i3) and got near linespeed, 111.4 MB/s = 890 Mbps. Putty SCP by comparison running from Win10 machine (i7) to Ubuntu box peaks around 32577.2 kB/s = 260 Mbps. WinSCP copy speed was comparable to Putty.
Its a Drobo5N2, and I've had it about 18 months.
I just checked the specs page and it does not mention CPU or RAM.
It recently pooped itself during a firmware upgrade.
The Drobo starts up but cannot mount the file system, so the NAS shares are unavailable.
Drobo support have been pretty good, they have issued me with 5-6 alternate firmwares to fix the issue but none have succeeded.
I am currently running a firmware that Drobo support supplied which allows me to access the file system using WinSCP from a Windows PC.
So I am copying the data off the Drobo (which is working but at a very slow speed) as Support now recommend rebuilding or resetting the NAS, upon which I will need to copy the data back on to it.
I do have some of the data backed up onto other disks (pre xmas sometime), but I dont see an easy way to do a compare or a synchronise, though it would definitely be quicker to only be copying the more recent stuff.
Delete cookies?! Are you insane?!
Here are some specs I found on a review website:
Delete cookies?! Are you insane?!
general speaking, if you got a dodge os /firmware but got working slow method to back it up, it best to let it happen over a few days, installing stuff, changing stuff could lead it a complete failure - get the data you want most first, then do a big copy of the rest, come back next week, and sort nas out when you got everything, anything else could lead to no backups
@nzkc yes, I have disabled Optimise Connection Buffer Size. Drobo Support recommended this at the start, so that must be a common issue.
And I have decided I need to work smarter as well.
There are some root folders with 1 nest deep of subfolders that should be easy to search for new items and I can just copy only those across.
These folders contain the about 12TB of the 15TB, and I dont think there will have been too many changes in them since the last backup.
That leaves just 3TB of stuff strewn across a myriad of nested subfolders, which would be easier to just copy in their entirety rather than sift through looking for the recent stuff.
So already I have reduced the task by 80%! :)
Thanks @bagheera for nudging my brain in that direction.
Delete cookies?! Are you insane?!
The issue is all scp tools you use for a NAS will always be slow. All NAS devices have an under-powered CPU that isn't optimised for user space activities such as scping vs transferring files via SMB aka CIFS aka Samba or NFS or FTP
I would just use teracopy to a SMB mount as that is a great copying tool.
Otherwise rsync is great to make sure that everything was copied across correctly and any deltas are copied too. You can either rsync over ssh which will be a similar speed to pscp/scp or if the NAS has a rsync server you can send it over rsync.
To make ssh tunnels ie pscp/scp/rsync over ssh go faster you need to disable compression and encryption on the SSH server and make sure the client isn't using encryption either.
Google is your friend.
|
![]() ![]() ![]() |