| Fred Stluka on 27 Mar 2017 08:07:23 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] Backups vs Copies: was Avoid Arvixe at all costs! |
Rich, I get a full backup, plus daily incrementals out of a single rsync command: % rsync -rpogtlv --del --backup --backup-dir=sparse src/ full This updates my full backup tree, but instead of overwriting or deleting files from that tree, it moves them to a new timestamped incremental tree that is sparsely populated only with the files that would have been changed or deleted. For details see: - http://bristle.com/Tips/Unix.htm#rsync_full_and_incremental_backup --Fred ------------------------------------------------------------------------ Fred Stluka -- mailto:fred@bristle.com -- http://bristle.com/~fred/ Bristle Software, Inc -- http://bristle.com -- Glad to be of service! Open Source: Without walls and fences, we need no Windows or Gates. ------------------------------------------------------------------------ On 3/16/17 7:43 PM, Steve Litt wrote:
On Thu, 16 Mar 2017 18:43:21 -0400 Rich Kulawiec <rsk@gsp.org> wrote:On Thu, Mar 16, 2017 at 04:52:01PM -0400, Ronaldo Nascimento wrote:Genuine question, what is the difference?[ between backups and copies ] Let me explain by example. Let's suppose that /home is your working filesystem and /home2 is its copy. You create the file "/home/fred" today at 5 PM. Tonight at 12:05 AM it gets rsync'd to /home2/fred -- along with everything else in /home. You now have a copy of /home/fred in /home2/fred. Tomorrow, you modify fred. You now have the current version of fred (Friday) in /home/fred, plus you have a backup of fred (Thursday in /home/fred2. Tomorrow night at 12:05 AM rsync runs again, and you now have the current version of fred (Friday) in /home/fred plus a copy in /home/fred2. What you no longer have -- anywhere -- is the Thursday version of fred. That's because it was copied over (well, rsync'd over). It's gone. Contrast with this: Let's suppose that /home is your working filesystem and /dumps is where you keep backups. You create the file "/home/fred" today at 5 PM. Tonight at 12:05 AM it gets dumped (via dump (8)) to /dumps/dump.thursday. Tomorrow, you modify fred. You now have the current version of fred (Friday) in /home/fred, plus you have a backup of fred (Thursday) in /dumps/dump.thursday. Tomorrow night at 12:05 AM dump(8) runs again, and you now have the current version of fred (Friday) plus a backup of fred (Friday) in /dumps/dump.friday plus a backup of fred (Thursday) in /dumps/dump.thursday. (Let's assume that you're using dump(8) in incremental mode with monotonically increasing levels, so that only the files modified since the previous day's run are backed up.) The point of this comparison is that if you wanted a copy, the first case gave you that; but if you wanted a backup, it didn't. Not really. But if you wanted a backup, the second case gave you that; but not a copy. Not exactly. (Dump's output is a single file that contains all of the files it backed up -- similar to tar, but quite a different format and with different metadata.)I don't completely understand what you say, but I think my system functions as both copies and backups. More after your next point...The larger point is that rsync makes copies, dump makes backups (and tar makes archives, hence its name). Each tool has its advantages and disadvantages, and sometimes one can be substituted for another is certain preconditions are met -- or if the task is some hybrid of copies/backups/archives. Folks have also built systems on top of them (notably using rsync in recent years) that provide the sort of incremental backup capability that dump's had since forever.The preceding sentence exactly describes my system. On my backup server, I run several shellscripts that begin rsync the latest data in directory /bup/rsync, and of course, rsync saves tons of time by transferring only files that have changed since their copies in /bup/rsync. Once the Rsync is through, I perform the following: cp -al rsync $datestamp Now /bup/$datestamp contains hardlinks to all the files in /bup/rsync. Later, as newer Rsyncs overwrite some of the files in /bup/rsync, the old files in /bup/rsync are deleted so that the only reference tothem is in the various /bup/$timestamp directories. In this way, I get both up to date backups, and I can go back and view (or restore) older versions. From what I hear, there's a newer technology that's better than cp -al, but I'm still using cp -al. Besides backups and copies, there are archives: Versions intended to last for decades, just in case. Every once in a while, on my backup server, I burn the backed up data (actually tarballs of the backed up data) to Blu-Ray, which I keep in a safe deposit box. I also have encrypted Blu-Ray archives stored in my house.The trick is figuring out which problem you're actually trying to solve, and having done that, selecting the right tool and using it the right way.That's for sure. What I want to do is recover from anything as trivial as an ill advised rm command to anything short of nuclear war. Additionally, I want to have access to files decades old, because on occasion I need them. And I want security and performance not offered by "Cloud Backup Solutions".SteveTSteve Litt March 2017 featured book: Troubleshooting: Why Bother? http://www.troubleshooters.com/twb ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug