On Thu, 2005-09-01 at 16:58, Ian Batten wrote:
>
> My suspicion is that the staging code is a part of Networker that's
> not as well-exercised as some others, and therefore some of the
> implications might not have been worked through.
Staging is not new. It's really just cloning with a few differences. The way
that people use backup-to-disk is probably still evolving, and I don't think
everyone has quite got it right, both from the design point of view and the
implementation point of view.
> You're
> right that the media database isn't committed to tape until the
> bootstraps go out at the end of
> a group, but I think most people would accept that `in progress'
> backups are a special case.
Ah - it's not as simple as that. Under normal circumstances the bootstrap only
gets saved by default in any group that includes the backup server. You would
expect that this is only once a day, YMMV. So in the worst case there could be
many dozens of volumes written to since the last backup of the bootstrap. So
the issue is not just limited to backups in progress.
> My worry with staging is that you could
> lose track of a backup which was done some time ago, and on which
> subsequent incrementals rely. In a largeish silo scanning all the
> tapes to find a specified saveset would be distinctly slow. Staging
> is one of the rare circumstances in which perfectly good, non-expired
> savesets are deleted. I can't think of another scenario in which a
> saveset which predates the most recent group completion would get
> lost in this way, and I can't see how I could intervene to save the
> bootstrap at the right point.
Personally I don't agree with the concept of just staging and deleting a save
set. If I am designing a system that backs up to disk I have two requirements
for an ideal system:
(1) Keep as much data on disk for as long as I can, for the fastest possible
recovery, and
(2) Get the data copied to tape as soon as possible for security.
The staging model as implied by the way NetWorker backup-to-disk is presented
does not achieve either of these objectives. You cannot really run your disk
devices at 99.9% full because the time it takes to stage a save set to disk
would impact on the time to do a backup - the save would need to wait until an
older save set has been staged to disk, defeating the object of disk backups.
And staging the data off when the disk is full is far too late in terms of data
security. It is possible to design your own scripts to do this whole thing
better, but the tools provided to enable this are lacking in a couple of ways.
I am still refining my system for doing this, but the point is that you
shouldn't need to do this in the first place.
Back to the question, by cloning the data as soon as possible and not deleting
it until space is required, you are fairly sure that the cloned data will
feature in a backed up bootstrap before the originals are deleted. Also with a
system controlled by scripts you can choose whether and when to run an
additional bootstrap backup.
A word of warning though, writing bootstraps too frequently can cause backup
failures due to the media database being unavailable for a short time during
the bootstrap backup.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the
body of the email. Please write to networker-request AT listserv.temple DOT edu
if you have any problems
wit this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
