I am trying to rsync the named files under /etc for backup purposes. I tried: rsync -ah --stats --delete -e "ssh -p613 -l root" 192.168.192.2:/etc/name* /home/rgm/data/htt/httnet/homebase/new/etc The stats shows it sees all the files, but only moves the dir /etc/named and the files within it. It does not move the /etc/name* files (like /etc/named.conf). By file count, it is 'seeing' all the files, but not moving them.
On Mon, 7 Sep 2015 13:05:59 -0400 Robert Moskowitz wrote:> I am trying to rsync the named files under /etc for backup purposes. > I tried: > > rsync -ah --stats --delete -e "ssh -p613 -l root" > 192.168.192.2:/etc/name* /home/rgm/data/htt/httnet/homebase/new/etc > > The stats shows it sees all the files, but only moves the > dir /etc/named and the files within it. > > It does not move the /etc/name* files (like /etc/named.conf). > > By file count, it is 'seeing' all the files, but not moving them.Hi Robert, First, a trailing slash specified at the end of the source directory means 'copy everything underneath the specified directory without copying the directory, itself.' Omitting the trailing slash will cause rsync to first create the directory at the target and then copy the specified contents underneath it. Your invocation '/etc/name*' probably needs to be split into successive command strings, one specifying the directory to backup and the other(s) specifying the file(s) under /etc that you want to backup, as well. Also: Do you really mean '-h' human-readable vs. '-H' preserve hard links? Why '-e' (specify remote shell to use)? Are these systems running disparate operating systems? I use '-v' so rsync echos what it's doing in real time to the terminal as opposed to '--stats', but that's just my personal preference. This allows me to monitor what's going on in real time and to scroll up afterward to review discreet actions after the fact. There is also the '-o' logging capability for those situations where the actions taken might exceed the number of lines buffered by the terminal. Since '--delete' implies that you will be synchronizing the source and backup directories in future, you might consider setting up public key authentication between the two systems. Since this is a backup, you really should consider preserving ACLs and extended attributes (-A -X,) too. Given all of the above, with public key authentication set up, you could then invoke the following command string from the parent directory of the backup (/home/rgm/data/htt/httnet/homebase/new/etc): rsync -avAX --delete root at 192.168.192.2:/etc/named/ named rsync -avAX --delete root at 192.168.192.2:/etc/named.conf named.conf ... and so on hth & regards, Carl
On 09/07/2015 02:17 PM, Carl E. Hartung wrote:> On Mon, 7 Sep 2015 13:05:59 -0400 > Robert Moskowitz wrote: > >> I am trying to rsync the named files under /etc for backup purposes. >> I tried: >> >> rsync -ah --stats --delete -e "ssh -p613 -l root" >> 192.168.192.2:/etc/name* /home/rgm/data/htt/httnet/homebase/new/etc >> >> The stats shows it sees all the files, but only moves the >> dir /etc/named and the files within it. >> >> It does not move the /etc/name* files (like /etc/named.conf). >> >> By file count, it is 'seeing' all the files, but not moving them. > Hi Robert, > > First, a trailing slash specified at the end of the source directory > means 'copy everything underneath the specified directory without > copying the directory, itself.' Omitting the trailing slash will cause > rsync to first create the directory at the target and then copy the > specified contents underneath it. Your invocation '/etc/name*' probably > needs to be split into successive command strings, one specifying the > directory to backup and the other(s) specifying the file(s) under /etc > that you want to backup, as well. > > Also: > > Do you really mean '-h' human-readable vs. '-H' preserve hard links?Yes.> Why '-e' (specify remote shell to use)? Are these systems running > disparate operating systems?Somewhere I read that is what you need to run this over SSH. Otherwise you need to have rsyncd running on the remote system.> I use '-v' so rsync echos what it's doing in real time to the terminal > as opposed to '--stats', but that's just my personal preference. This > allows me to monitor what's going on in real time and to scroll up > afterward to review discreet actions after the fact. There is also the > '-o' logging capability for those situations where the actions taken > might exceed the number of lines buffered by the terminal. > > Since '--delete' implies that you will be synchronizing the source and > backup directories in future, you might consider setting up public key > authentication between the two systems.This is not an automated system. It is typically a onetime thing to get a backup of what I did to set up a server (or the other way around). I have this adversion of leaving my public key all over the place.> Since this is a backup, you really should consider preserving ACLs and > extended attributes (-A -X,) too.Maybe, but then I can't edit it on my system if it is root:named!> Given all of the above, with public key authentication set up, you > could then invoke the following command string from the parent > directory of the backup (/home/rgm/data/htt/httnet/homebase/new/etc): > > rsync -avAX --delete root at 192.168.192.2:/etc/named/ named > rsync -avAX --delete root at 192.168.192.2:/etc/named.conf named.confIn /etc there are 4 named.* files. Do I have to do each separately?> ... and so on > > hth & regards, > > Carl > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
I tried your rsync command and it worked on my LAN over ssh. The following was placed in the destination directory: drwxr-x--- 2 root smmsp 4.0K Jul 28 21:05 named/ -rw-r----- 1 root smmsp 1.6K Oct 30 2013 named.conf -rw-r--r-- 1 root smmsp 2.4K Jul 28 21:05 named.iscdlv.key -rw-r----- 1 root smmsp 931 Jun 21 2007 named.rfc1912.zones -rw-r--r-- 1 root smmsp 487 Jul 19 2010 named.root.key On Mon, Sep 7, 2015 at 1:05 PM, Robert Moskowitz <rgm at htt-consult.com> wrote:> I am trying to rsync the named files under /etc for backup purposes. I > tried: > > rsync -ah --stats --delete -e "ssh -p613 -l root" 192.168.192.2:/etc/name* > /home/rgm/data/htt/httnet/homebase/new/etc > > The stats shows it sees all the files, but only moves the dir /etc/named > and the files within it. > > It does not move the /etc/name* files (like /etc/named.conf). > > By file count, it is 'seeing' all the files, but not moving them. > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
On Tue, 8 Sep 2015 10:25:33 -0700 (PDT) Mark Milhollan wrote:> On Mon, 7 Sep 2015, Carl E. Hartung wrote: > >On Mon, 7 Sep 2015 13:05:59 -0400 > >Robert Moskowitz wrote: > > >> rsync -ah --stats --delete -e "ssh -p613 -l root" > >> 192.168.192.2:/etc/name* /home/rgm/data/htt/httnet/homebase/new/etc > > >Why '-e' (specify remote shell to use)? Are these systems running > >disparate operating systems? > > -e specifies the *local* transport command to useWhat?! Straight from the documentation: " -e, --rsh=COMMAND specify the remote shell to use"> , and in this case it also specifies the remote port (613) and user > (root). Granted one should probably use their ssh configuration to > do that but it isn't realy "wrong" (to be questioned) to do it via > options.I didn't explicitly state that it was "wrong," just implied (correctly) that it was unnecessary.> > > /markregards, Carl
I ran it again but with: rsync -ah --stats --delete -e "ssh -p613 -l root" 192.168.192.2:/etc/name* /home/rgm/data/htt/httnet/homebase/new/newetc And the newetc directory was created with all the files. I again ran: rsync -ah --stats --delete -e "ssh -p613 -l root" 192.168.192.2:/etc/name* /home/rgm/data/htt/httnet/homebase/new/etc And none of the /etc/name.* files get moved. Strange. Well I got my backup. On 09/07/2015 06:04 PM, Mike wrote:> I tried your rsync command and it worked on my LAN over ssh. > The following was placed in the destination directory: > > drwxr-x--- 2 root smmsp 4.0K Jul 28 21:05 named/ > -rw-r----- 1 root smmsp 1.6K Oct 30 2013 named.conf > -rw-r--r-- 1 root smmsp 2.4K Jul 28 21:05 named.iscdlv.key > -rw-r----- 1 root smmsp 931 Jun 21 2007 named.rfc1912.zones > -rw-r--r-- 1 root smmsp 487 Jul 19 2010 named.root.key > > > On Mon, Sep 7, 2015 at 1:05 PM, Robert Moskowitz <rgm at htt-consult.com> > wrote: > >> I am trying to rsync the named files under /etc for backup purposes. I >> tried: >> >> rsync -ah --stats --delete -e "ssh -p613 -l root" 192.168.192.2:/etc/name* >> /home/rgm/data/htt/httnet/homebase/new/etc >> >> The stats shows it sees all the files, but only moves the dir /etc/named >> and the files within it. >> >> It does not move the /etc/name* files (like /etc/named.conf). >> >> By file count, it is 'seeing' all the files, but not moving them. >> >> >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> https://lists.centos.org/mailman/listinfo/centos >> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos >
On Wed, 9 Sep 2015 05:51:38 -0700 (PDT) Mark Milhollan wrote:> On Tue, 8 Sep 2015, Carl E. Hartung wrote: > >On Tue, 8 Sep 2015 10:25:33 -0700 (PDT) Mark Milhollan wrote: > > >> -e specifies the *local* transport command to use > > > >What?! Straight from the documentation: > > > >" -e, --rsh=COMMAND specify the remote shell to use" > > If only one can properly interpret the meaning... COMMAND is the > local command to run to obtain a remote (non-interactive) shell, so > it isn't that the remote shell program (invoked once the transport is > connected) is being specified, i.e., it is which `remsh' to use. The > -p and -l provided thereby may be necessary, since the one is not the > default and the other isn't known to us to be the same as the local > user, which you glossed over as if one never has a need to specify. > > Orthogonal to Robert's problem, the switch from default use of rsh to > ssh has made it a requirement for (good) automation to always supply > a -e to ensure the correct command is used to account for all > potential versions of rsync that may be used. > > >> , and in this case it also specifies the remote port (613) and user > >> (root). Granted one should probably use their ssh configuration to > >> do that but it isn't realy "wrong" (to be questioned) to do it via > >> options. > > > >I didn't explicitly state that it was "wrong," just implied > >(correctly) that it was unnecessary. > > Potentially unnecessary. Just because you might see putting the port > and user in the ssh config file as the right thing to do, and which I > also do whenever possible, doesn't mean Robert necessarily wants to > or can do so, and after all -e does exist. Your questioning its use > as you did implied using it is wrong, to which I object. Luckily you > decided to reply to the list quoting me so eventually Robert was > supplied with the clue you didn't provide, that it might be > pre-configured. > > > /markMark, I would prefer it if you would please send your replies to the list and not to me personally. I *do* get them if you send them to the list. All of these fine grained points you've made regarding options that are "required for (good) automation" are irrelevant. Robert's post concerned invoking rsync manually "for backup purposes" -- not for "automation" as you're envisioning. He wrote "This is not an automated system. It is typically a onetime thing ..." Moreover, my "Why '-e'?" query was paired with a second very specific question: "Are these systems running disparate operating systems?" The implication seems pretty clear to me -- not that '-e' was somehow "wrong" but simply likely unnecessary in his scenario. I stand by that somewhat informal (less strict than you) evaluation unless and until we learn that he's actually operating on truly disparate systems. regards, Carl
On 09/09/2015 08:17 PM, Carl E. Hartung wrote:> On Wed, 9 Sep 2015 05:51:38 -0700 (PDT) > Mark Milhollan wrote: > >> On Tue, 8 Sep 2015, Carl E. Hartung wrote: >>> On Tue, 8 Sep 2015 10:25:33 -0700 (PDT) Mark Milhollan wrote: >>>> -e specifies the *local* transport command to use >>> What?! Straight from the documentation: >>> >>> " -e, --rsh=COMMAND specify the remote shell to use" >> If only one can properly interpret the meaning... COMMAND is the >> local command to run to obtain a remote (non-interactive) shell, so >> it isn't that the remote shell program (invoked once the transport is >> connected) is being specified, i.e., it is which `remsh' to use. The >> -p and -l provided thereby may be necessary, since the one is not the >> default and the other isn't known to us to be the same as the local >> user, which you glossed over as if one never has a need to specify. >> >> Orthogonal to Robert's problem, the switch from default use of rsh to >> ssh has made it a requirement for (good) automation to always supply >> a -e to ensure the correct command is used to account for all >> potential versions of rsync that may be used. >> >>>> , and in this case it also specifies the remote port (613) and user >>>> (root). Granted one should probably use their ssh configuration to >>>> do that but it isn't realy "wrong" (to be questioned) to do it via >>>> options. >>> I didn't explicitly state that it was "wrong," just implied >>> (correctly) that it was unnecessary. >> Potentially unnecessary. Just because you might see putting the port >> and user in the ssh config file as the right thing to do, and which I >> also do whenever possible, doesn't mean Robert necessarily wants to >> or can do so, and after all -e does exist. Your questioning its use >> as you did implied using it is wrong, to which I object. Luckily you >> decided to reply to the list quoting me so eventually Robert was >> supplied with the clue you didn't provide, that it might be >> pre-configured. >> >> >> /mark > Mark, I would prefer it if you would please send your replies to the > list and not to me personally. I *do* get them if you send them to the > list. > > All of these fine grained points you've made regarding options that are > "required for (good) automation" are irrelevant. Robert's post > concerned invoking rsync manually "for backup purposes" -- not for > "automation" as you're envisioning. He wrote "This is not an automated > system. It is typically a onetime thing ..." > > Moreover, my "Why '-e'?" query was paired with a second very specific > question: "Are these systems running disparate operating systems?" The > implication seems pretty clear to me -- not that '-e' was somehow > "wrong" but simply likely unnecessary in his scenario. I stand by that > somewhat informal (less strict than you) evaluation unless and until we > learn that he's actually operating on truly disparate systems.Fedora22 and Centos7.
On 09/09/2015 08:17 PM, Carl E. Hartung wrote:> On Wed, 9 Sep 2015 05:51:38 -0700 (PDT) > Mark Milhollan wrote: > >> On Tue, 8 Sep 2015, Carl E. Hartung wrote: >>> On Tue, 8 Sep 2015 10:25:33 -0700 (PDT) Mark Milhollan wrote: >>>> -e specifies the *local* transport command to use >>> What?! Straight from the documentation: >>> >>> " -e, --rsh=COMMAND specify the remote shell to use" >> If only one can properly interpret the meaning... COMMAND is the >> local command to run to obtain a remote (non-interactive) shell, so >> it isn't that the remote shell program (invoked once the transport is >> connected) is being specified, i.e., it is which `remsh' to use. The >> -p and -l provided thereby may be necessary, since the one is not the >> default and the other isn't known to us to be the same as the local >> user, which you glossed over as if one never has a need to specify. >> >> Orthogonal to Robert's problem, the switch from default use of rsh to >> ssh has made it a requirement for (good) automation to always supply >> a -e to ensure the correct command is used to account for all >> potential versions of rsync that may be used. >> >>>> , and in this case it also specifies the remote port (613) and user >>>> (root). Granted one should probably use their ssh configuration to >>>> do that but it isn't realy "wrong" (to be questioned) to do it via >>>> options. >>> I didn't explicitly state that it was "wrong," just implied >>> (correctly) that it was unnecessary. >> Potentially unnecessary. Just because you might see putting the port >> and user in the ssh config file as the right thing to do, and which I >> also do whenever possible, doesn't mean Robert necessarily wants to >> or can do so, and after all -e does exist. Your questioning its use >> as you did implied using it is wrong, to which I object. Luckily you >> decided to reply to the list quoting me so eventually Robert was >> supplied with the clue you didn't provide, that it might be >> pre-configured.I just tried the following: rsync -ah --stats "ssh -p613 -l root" 192.168.192.2:/root/samba.PDC/ /home/rgm/data/htt/httnet/homebase/new/root/ And it failed with: Unexpected remote arg: 192.168.192.2:/root/samba.PDC/ rsync error: syntax or usage error (code 1) at main.c(1330) [sender=3.1.1] I tried again with: rsync -ah --stats -e "ssh -p613 -l root" 192.168.192.2:/root/samba.PDC/ /home/rgm/data/htt/httnet/homebase/new/root/ and it worked. This is what I read from the manpage, that "-e" is needed for the ssh command.