Argh. Thunderbird strikes again. The list should really be the
Reply-To: on these articles!
Sorry, Les :-)
-------- Original Message --------
Subject: Re: [BackupPC-users] Host Backup Summary
Date: Mon, 29 May 2006 21:03:34 -0400
From: Bill Hudacek <[EMAIL PROTECTED]>
To: Les Mikesell <[EMAIL PROTECTED]>
References:
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Les Mikesell wrote:
>
> I've heard the differential term before, but can't place it with
> any of the standard unix tools (tar, dump, cpio, etc.). Can
> you point out a man page that covers this distinction?
>
Sorry, man pages were never anything I've wanted to brag about when it
comes to *NIX and this is a case in point :-)
However, a quick google search found this:
Comparison differential vs. incremental backups
http://www.drivesnapshot.de/en/differential.htm
and
Backup and Restore Solution for Windows 2000–based Data Centers
Chapter 1 - Backup and Restore Design
http://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/backuprest/br01.mspx
Search both those pages for incremental, I think you'll find they agree
with my description...
(note: looks like Microsoft purchased CommVault - they were a good
vendor, back in the day, they provided optical jukeboxes to backup
"huge" amounts of data to CDROMs. I wonder if they are still worth the $$)
>
>>I would have been happiest with a three-tiered backup model in backuppc,
>>as my use of an "on-line backup server" means having 1 full, the latest
>>differential (say, from "full + 3 weeks"), and three incrementals to
>>restore is not an inconvenience at all.
>
>
> These distinctions don't make a lot of sense with the way backuppc
> does things. All duplicate copies are merged, so it doesn't
> take much more space to store another full compared to an
> incremental. Backuppc always merges the full and incremental
> during the restore so there is no apparent difference there
> either. The differences really relate to the transfers and
> the quirks vary according to the transfer method.
>
You're absolutely correct, Les, and it's a point about storage that I
didn't explicitly make in my initial comments.
There is still the bandwidth requriement(s) (find all files that have
changed in the last 30 days vs find all files that have changed in the
last 24 hours). And, as you pointed out, the cost here depends on the
backup mechanism, which was not evident in my simplistic statements.
>
>>However, having said that - with my BackupPC environment, instead of
>>running a full backup once a month, and having differentials weekly,
>>with incrementals daily, I simply run fulls weekly and thus the
>>"differentials" that backuppc calls "incrementals" do not ever approach
>>the cost of a full backup (which I would consider not just an
>>inconvenience but a serious problem).
>
>
> With tar and smb fulls actually transfer a complete copy
> over the network but duplicates are identified and replaced
> with links on the server side. Incrementals work strictly
> by timestamp and thus will miss old files under renamed
> directories in the tar case (working with ctime) and any
> backdated file (copied with any method that preserves an
> old timestamp) in the smb case. With rsync, all files are
> checked but the difference is that the incremental runs
> check only directory entries (timestamp/length) on existing
> files - fulls do a block checksum comparison with the
> rysnc algorithm. The comparison is always against the last
> full run, though, so incrementals keep growing in size. It
> might be possible to tweak the options in the rsync command
> to make a full run also trust the directory information
> to make fulls go faster.
>
The salient point I was making was that I was a bit surprised that it
was not possible (let's use the rsync case) to make the timestamp/length
checks be against the latest backup --- of any type --- rather than just
against a full.
As you pointed out above, this & other approaches can suffer from
integrity issues (my favorite is "not knowing that a file has been
deleted"). I for one could accept that in return for a backup that runs
in 5 minutes - most of my differentials (er, "backuppc incrementals")
after a week or so run for more than 2 hours on a 60+GB linux laptop or
server - especially since, with the "merged" or "filled-in" restore/view
of a machine's backups, you would not know the difference when doing a
restore.
--
Regards,
Bill Hudacek
"Redundancy is good; triple redundancy is twice as good!" - me
--
Regards,
Bill Hudacek
"Redundancy is good; triple redundancy is twice as good!" - me
_______________________________________________
BackupPC-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
