I would like to have my backups rsync to a local server at my house, redacted.contoso.com.
When I try to save the connection, the miab admin console throws the error:
Connection to rsync host failed: The hostname redacted.contoso.com cannot be resolved
I suspect this is because the miab hosts the DNS for contoso.com. But if I digcontoso.com via SSH, it resolves with no issue. I can even dig @localhost and it works! Is there something I’m missing? Or is this a bug?
If you are using example/filler names, you should use example.com, domain.com or some equally obvious fake domain name.
The plain simple fact is that nobody can help troubleshoot when the person seeking help is reluctant to provide the relevant details. So, if you wish to PM me with actual hostnames/domains, I would be willing to check things further … otherwise, I cannot help you.
Have you considered having your backup server pull the backups with a daily cron job instead? This was the path that I took as it ended up being much simpler.
Sorry, “contoso” is in regular use as example data for lots of Microsoft stuff and I assumed it would be taken as such. Sorry!
Ultimately I decided to go with your approach, using a cronjob and lftp to mirror the for contents. I’d love to know why it won’t resolve the hostname, though.
Ahh, that makes sense … although I avoid M$ like the plague, so had no idea. Thanks for teaching me something new.
I am not familiar with lftp, and a quick Google search shows that it may be a good choice. However, I recommend using rsync. Again, you may be using a good alternative as it does look as though lftp synchronizes rather than just copies. I chose rsync because it only updates the changes, so there is typically much less data transfer involved.
As for why the hostname is ‘not resolved’ … I am honestly not certain. Quite often, people make simple unobvious mistakes with DNS, which from the info you PM’d me is not the case here. For me, MiaB would NOT use an alternate port with rsync, so I decided to pull the backups rather than push them - this was months ago before a solution was found that works.
Have you tried just testing backups via rsync with the IP address? Just to confirm that backups are working properly in the first place … this obviously would not work going forward but it would certainly help eliminate potential other issues.
I think I have it figured out. SSH is listening on a non-standard port on that system. I have a containerized SFTP-only service that listens on 22 which allows me to conveniently jail users and restrict content.
The unexpected side effect is that rsync is unavailable without a shell. I think it’s simply failing to connect, but reporting it as failing to resolve. Making my case: at your suggestion, I tried the IP - same error.