Warren,

Just want to say thanks.  I have my automated backups going now. Good old cronie.

Since I have a cat6 line to my neighbor (as a favor for their net access), I only have to move the backup box to his house and I have off-site backups for $150 outlay (arm SOC and 4 TB drive) and <$50/yr electric (our rate is ~$0.21/KWH).  You can't buy cloud storage for that price.

On 08/03/2018 12:17 PM, Warren Young wrote:
On Aug 3, 2018, at 9:59 AM, Robert Moskowitz <r...@htt-consult.com> wrote:
You haven’t needed "-e ssh” since rsync 2.6.0, which made it the default.  It 
was released in 2004.
How do I specify -p and -l that I cut out of my example?
Add it to ~/.ssh/config:

     Host nevia.htt-consult.com
         Port 2222
         User rmoskowitz

You might not think of rsync as paying attention to this file, which is 
correct, because it doesn’t.  But since it is executing ssh under the hood, and 
ssh *does* pay attention to that file, it takes effect.

If you’re creating that file for the first time, be sure to chmod 600 it.  Ssh 
will ignore it if it’s not locked-down.  RTFM for details.

/var/flexshare/shares 
x.htt-consult.com:/media/backup/homebase/var/flexshare/shares/
Rsync won’t create multiple levels of directories on the target.  It will only 
create up to one level of missing directories.  Try this:

     $ ssh x.htt-consult.com 'mkdir -p 
/media/backup/homebase/var/flexshare/shares/'
Oh?  I have been doing this in one shape or form for a long time.
Let me clarify:

If only /media/backup exists on the remote machine, I believe you’ll end up 
with /media/backup/shares with that command.

If at least /media/backup/homebase/var/flexshare exists, rsync will always create 
“shares” under “flexshare" on the remote host.

Anything below that level will also be created, regardless of depth.  I’m 
speaking only of the target path given as the last argument to rsync here, not 
of the source machine’s directories discovered during the sync process.

It’s possible this behavior changed since I last looked at it.  I ran into this 
issue many years ago and now ensure that the target path passed to the rsync 
command exists on the remote host before starting the sync.
_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Reply via email to