13 thoughts on - Grsync For CentOS 7

• Use the –dry-run rsync option to test things out. It tells you what it’s going to do but doesn’t actually make any changes.

  ❧ Brian Mathis
  @orev

  CentOS mailing list CentOS@CentOS.org http://lists.CentOS.org/mailman/listinfo/CentOS

• What are you trying to do, and what kind of mistakes are you worried about? The only things I find confusing are what the trailing /
  means on a directory name and that -H isn’t bundled with the other options that -a includes that you normally want. You can avoid the ambiguity of whether the top directory or just the contents will be copied by cd’ing into the source directory and doing:
  rsync -av . host:/path/to/dir. That is, by using ‘.’ as the source you can’t mistakenly create another directory level on the target. And you just have to remember that it will create the final directory in the target path if it doesn’t exist, but just the final one, not the whole path.

  And if you add -n or –dry-run to the options along with -v, it will go through the motions and show you the files that would be transferred without actually doing it.

• The fact that you need a paragraph this long to describe how to avoid some of the confusion when using rsync pretty much speaks for itself. Rsync definitely has its own syntax and is much more sensitive than other unix tools, so it’s not unwarranted that people might be confused. I don’t know anyone who fully understands the include/exclude filters either, at least not without rereading the man page a few times.

  ❧ Brian Mathis
  @orev

• Thanks for the replies.

  1) I always use the -n (–dry-run) option. Couldn’t imaging not doing so!

  2) I hate having to look up stuff like the trailing slashes each time. And trying to decide what to (–exclude), to -H or not to -H, etc.

  3) I hate having to re-do #2 every time I want to do a small ad-hoc backup or synchronization, let alone a full filesystem backup.

  4) I could do shut down, reboot, and run Grsync from a cd or USB stick. But what a hassle for minor, ad-hoc stuff. Should only have to do that for full backups.

  5) If Grsync was in CentOS before, why was it removed? “Because it’s not in RHEL.” Okay, but why not?

  6) While I do really appreciate CLI stuff, more and more I have come to appreciate GUI stuff. Someday, I think you too will understand.

  7) Again, hasn’t anyone installed Grsync in CentOS 7 from source? I hate to being the “lab rat”.

• ​Just to note, it does seem to be in the base for Fedora-21, so maybe it will come back in CentOS-8​.
  ​Note sure why it seems to have been removed. ​ Try posting on the EPEL
  list. You may be able to convince someone to add it there.

• ​Just to note, it does seem to be in the base for Fedora-21, so maybe it will come back in CentOS-8​.
  ​Note sure why it seems to have been removed. ​ Try posting on the EPEL
  list. You may be able to convince someone to add it there.

• If you are doing system backups regularly with manual command line runs, I’d recommend looking at BackupPC (well I’d recommend it even more if you aren’t doing regular backups…). But it works best with a 2nd system doing the work and might not be a replacement for rsync to a removable drive.

• I can’t find any evidence it was ever in RHEL or CentOS. It looks like it’s in the Nux Desktop repo and the Repoforge repo for EL5 and 6 and Nux for EL7.

  I really doubt that. Someday, maybe, you’ll understand why some people prefer the command line interface.

  The Fedora packages rebuild fine for epel7 (I just tested it), so I
  would assume that’d be the best place to start if you wanted to build your own packages. Or you could just use the Nux Desktop repo.

  See:
  http://wiki.CentOS.org/AdditionalResources/Repositories

• Thanks!

  The Grsync package from the Nux repository does seem to work so far (3
  days, light usage).

  Since I am obsessive about updating using yum, after installation I
  immediately disabled the Nux repository from updating, due to the dire warnings in the CentOS documentation about the risks of using add-on repositories.

  So far so good.

  And FWIW, I do like, and use the CLI all the time. That’s how I learned –
  using MS-DOS 3.2 on a 386sx box with 360k floppy drives. And 512k ram –
  what luxury!

  : )

• Francis Gerund wrote:
  
  – using MS-DOS 3.2 on a 386sx box with 360k floppy drives. And 512k ram
  – what luxury!

  You leaned on a 386 with (2?) floppy drives? I had to make do with DOS 3.0
  on an 8088 w/ 2 floppy drives… and let me tell you how much fun it was to compile (I kid you not) basica, esp. with an encrypted library….

  mark

• Upon reflection, recall that first “real” computer actually had 8088
  processor (8-bit deliberately crippled version of 16-bit 8086 processor). Second one was the 386sx (16 bit deliberated-crippled version of 32-bit 386
  processor).

  Unless you count the Timex-Sinclair 1000 (z80 processor, i/o from cassette tape storage) .

  Before that, at university:

  – IBM 370 series mainframe, in locked room, inaccessible to mere mortals.

  – programs entered on punch cards using key-punch machine, submitted through small window in computer room.

  – come back for dot-matrix printout of results Thursday.

  – edit program for errors, until assignment deadline passes.

  – rinse, lather, repeat. What fun.

  Is this thread getting to be [OT]?

• <4yorkshiremen>
  Floppy drives? Floppy drives! Wot lukxxxuuury! We woul’da killed for floppy drives. I remmebr when dad brought hoom papirr punch tape for the first time. And we had needles to program it widt. . . .

• James B. Byrne wrote:
  512k

  Oh, well, if you’re going to what’s at home, I still fondly remember my CoCo (RadShack Color Computer), and IIRC, there was a way to plug in a cassette recorder, and the b’day present that my ex and a friend did, voiding the warranty, doubled the memory to 32k….

  mark “school, of course, was punch cards for the time-shared 370”