From: Les M. <les...@gm...> - 2013-10-19 16:37:35
|
On Fri, Oct 18, 2013 at 6:11 PM, Holger Parplies <wb...@pa...> wrote: >> >> Personally, I would just use rsync over ssh like any other target and >> not worry about the CPU doing a little extra work. It's probably not >> doing much else then anyway... > > While I agree with rsync, I don't see the point of ssh, and you're completely > ignoring the fact that there was some thought behind using the script - as if > you were trying to "trick" Phil into getting rid of it. No, the reason that I use - and recommend - it is to eliminate special cases. Rsync over ssh 'just works' and can be the same everywhere. > You also seem to be > missing that it's a local backup, so the CPU is probably doing compression > (as well as both sides of the ssh), and it might even be running concurrent > backups. Yes, but my philosophy is that the machines are supposed to be doing the work instead of people - that's why we have them. So I'll let the CPU do a few extra cycles as a tradeoff for not wasting a weekend figuring out which quote was misplaced in a special case instance or why one instance works and another one doesn't. > While replacing tar with rsync *inside* the script avoids the problem of > needing to escape the date, it does *not* avoid needing to escape the > $argList. While you might get away with an incorrect setting as long as > there happens to be nothing requiring quoting, you'll be surprised some > day when it stops working because you change your backup set, so do > yourself a favour and get it right now, whether with tar or with rsync. And don't forget the point that tar incrementals can miss things that rysnc will catch. -- Les Mikesell les...@gm... |