[PLUG] Backups vs Copies: was Avoid Arvixe at all costs!

[Steve Litt <slitt@troubleshooters.com>]

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".
 
SteveT

Steve 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