On (old) WD NAS devices supporting Safepoint the target device could be anything supporting the source device’s level of SMB. On later devices (such as MyCloud Gen 2) there is no mention of using a non-WD target. Is this possible?
I have a non-WD NAS that has rsync support. I’ve read hints that the MyCloud Remote Backup uses rsync but I’ve not seen this confirmed. (And I don’t know much about rsync so I’m really flying blind here.)
The MyCloud Remote Backup job setup isn’t exactly as I suspected. It asked fo either more or less name/password information than is needed:
Password
SSH User name
SSH Password
If “Password” is the remote username’s password, what is the username?
Are the SSH User name and password for the local MyCloud SSH support? If remote, what’s the difference between “Password” and “SSH Password”
Hmm. I seem to have put two completely different questions in that posting. Ignore the 1st paragraph; it belongs in a different thread - nothing to do with Remote Backup or rsync.
Now, on to your response, I have enabled SSH on the MyCloud device with no problem. I can use puTTY on Windows to log onto MyCloud via SSH (although I don’t have any idea what to do once I’m there). I also have successfully enabled SSH on the target (non-WD) NAS.
My question really has to do with what I do next. I think the first “Password” field is the password for my local SSH client on MyCloud. I think the other fields (SSH user name and SSH Password) are for the SSH server on the remote NAS. But the log on the target NAS seem to show that MyCloud is trying to log onto the target NAS with user name “sshd” regardless of the “SSH user name” I put in the Remote Backup definition. (That makes no sense. I’ll have to check that again.)
Given that MyCloud was trying to log in using “sshd” I created an account for sshd on the target and gave the the Remote Backup definition the associated password but I get an authentication error of some sort on the target NAS.
I suspect I’ve got something wrong on the target NAS but I really need to know how MyCloud is using the Remote Backup definition fields in order to proceed.
I have fought the built in “ssh sync to remote” web panel on the gen2 mycloud very hard. The way it is coded, it actually checks if this is a single bay unit, and if so, it purposefully disables functionality that allows it to communicate with multibay or *nix hosts. It FORCES it to act stupid, purely for marketing reasons.
As a stopgap, I suggest configuring your more intelligent host to do a “pull” FROM the mycloud, and to initiate it itself. That way the MyCloud is just responding to the rsync over ssh, rather than trying to initiate it.
Oh. I thought it was the target that could not be single bay (which makes as little sense). So there is no way to rsync from a single bay MyCloud?
Unfortunately, I don’t really know anything about Linux and rsync so there is going to be a learning curve here, but if you know the “pull” works I’ll start working on that.
Yes you can use rsync to copy files to or from a remote NAS so long as that NAS supports such access. If you haven’t done so already, use the forum search feature (magnifying glass icon upper right) and search for remote rsync, there are several past discussions that appear to discuss such an operation.
Couple of notes. One will have to configure the router at the remote location to allow the rsync traffic to enter the remote network and be directed to the remote NAS. You will have to learn how to issue various Linux commands via SSH including how to issue Rsync commands and SSH commands to access a remote NAS. One can use their favorite Interent search engine to being reading up on how use Rsync to copy from one NAS to another.
[quote=“Bennor, post:6, topic:220681”]
One will have to configure the router at the remote location to allow the rsync traffic to enter the remote network and be directed to the remote NAS.[/quote]
This is all on my LAN. One I get it working the non-WD NAS will be moved to a semi-hardened location well away from the rest of my computer equipment (requiring a bit of Ethernet cabling). I won’t need to make any router/firewall changes.
[quote=“Bennor, post:6, topic:220681”]
You will have to learn how to issue various Linux commands via SSH including how to issue Rsync commands and SSH commands to access a remote NAS.[/quote]
Well, that looks like it might be the solution if I can automate it. I’ve actually got 3 WD NAS devices - 2 MyBookLives and 1 MyCloud and both types have problems with “push” backups. (The MBLs could do Safepoint backups if they could see shares on the target, but those seem to be hidden.)
I did a small rsync pull from the MC and I’m about 5 hours into a large rsync pull from one of the MBLs. It seems to be working fine but I initiated it with a command sent on an SSH session and got prompted for a password since the rsync command has no way to include the password. That makes scripting difficult. It’s a good proof of concept, though. The pull is working.
There are ways to automate the user/pass with rsync. Just doing so is not exactly the most security conscious thing in the known universe.
You already specify the user with the rsync syntax, you just need to pass the password to rsync programmatically. This is easily accomplished with an environment variable; rsync actually looks for it, and rolls with it if it is set.
This will allow your more intelligent device to have a scheduled rsync, and communicate with the mycloud totally programatically.
The safest way of course, is to use a password file with rsync, that is properly secured against being read by non-authorized users, and executing the script with the right user credentials… but meh.
If any of the other NAS devices can do a scheduled script, you can have one TELL the others to do the rsync, using rsh.
rsh is a bit like ssh, and uses the same protocols. What it does, is tell a remote host to execute a single command line instruction. It too can be automated with environment variables to contain passwords. EG, the one host that can fire off reliable automation scripts, can issue rsh instructions to the devices that do not, and they can then all do the needful. Even if that “one host” is your local admin terminal (less than optimal, but if it is always on, it can work just fine.)
