On Thursday 10 July 2008 17:17:25 mark.bergman AT uphs.upenn DOT edu wrote:
> In the message dated: Thu, 10 Jul 2008 13:45:02 +0200,
> The pithy ruminations from Kern Sibbald on
> <[Bacula-users] Vbackup feature> were:
> => Hello,
> =>
> => I'm a bit burned out from intensive bug fixing over the last couple of
> months, => so decided to do something totally new yesterday. I started
> implementing => what I call Virtual Backup or Vbackup, which is essentially
> project #3 "Merge => multiple backups (Synthetic Backup or Consolidation)".
>
>
> Yeah!
>
>
> =>
> => In attempting to implement it, I've realized a few things:
> =>
> =>
> => 2. In most all respects it must behave much like a Migration job in that
> it => does not use a FD, it reads an existing set of backups, and writes
> them to a => new Volume.
>
> Huh?
Read the doc on Migration.
>
> =>
> => 3. One difference from a Migration job is that all the old jobs remain
> => unchanged (i.e. like a Copy).
>
> OK...if they old jobs remain unchanged, then why copy all those millions of
> bits from physical media to physical media?
No need to copy any bits. Don't run a vbackup. See the file "projects" Item
#3.
>
> =>
> => 4. Another difference is that it has many fewer features in that it
> simply => finds all the current backup records and copies them. There are
> no => complicated selection criteria.
>
> Sounds good.
>
> =>
> => 5. Like the Migration and Copy jobs, the input Pool (from where it reads
> the => currently backed up data) and the output Pool (where it writes the
> merged => data) must be different. This ensures that the job does not
> attempt to read => and write to the same device, which just will not work.
> =>
> => Well the problem with the above -- principally item #5 is consider the
> => following:
> =>
> => You have a job J1, which does a Full, one or more Diff backups, then any
> => number of Inc backups all going to Pool P1. At some point in time
> (possibly => via the Schedule), you run a vbackup level, so it finds all
> the current => backup files (Full, last Diff, and all later Inc) and copies
> the data from ^^^^^^^^^^^^^^^
>
> I haven't been following the development list closely, so please forgive me
> if what I'm asking has already been discussed...perhaps I'm completely
> off-track...
>
> Why copy the data at all? I see vbackups as being most useful for sites
> with a lot of data. If the data needs to be copied from one set of physical
> media to another, that would:
>
> be very slow -- the vbackup may take longer than a real backup (ie.,
> read multiple tapes, compute the virtual backup, then write to multiple
> tapes)
>
> require significan server resources (how will multi-TB backups be
> "virtualized" without requiring tremendous spool space or RAM, if the
> actual backup data is being copied)
>
> tie up physical resources (tape drives, slots in a tape changer, etc)
>
> require human resources (ie., inserting tapes, mounting external
> drives, etc)
Then don't run any vbackups. The rest of us, providing we have "Accurate =
yes" will find them very useful.
>
> What happens if the Full or last Diff that bacula wants to use in the
> vbackup aren't physically available (ie., they're not in the tape changer,
> those USB drives or DVDs aren't mounted, etc.)?
Same thing that happens when you do a restore under the same conditions.
>
> I had thought that a virtual backup would operate at the database level as
> much as possible, in other words, when a vbackup is run, then the the
> current backup files (Full, last Diff, and all later Inc) are "tagged"
> within the database as being used for both the physical backup where they
> were created and for the virtual backup.
No, read item #3
>
> I can understand writing records to physical media that represent the
> "diff" between the current state and the combined backups that were already
> made. In other words, the results of a vbackup would be something like a
> ".bsr" file, specifying which existing physical backups would be used (in
> order), then specifying a new backup that would be (virtually) superimposed
> on that result--the new backup being the "diff" between the combined
> existing backups and the current state of the client filesystem. The only
> things written to media would be that "diff" and database updates that flag
> existing jobs as being associated with the new vbackup.
You are discussing something totally different.
>
> This would have the side effect of extending the expiration period on the
> physical media (ie., if a tape contains a 5-month old Full backup and full
> backups (and the media) have an expiration period of 6 months, and that
> tape is then flagged as part of a vbackup, the existing Full job record
> would expire as normal, but the media and data records from the old Full
> backup would not be purged until 6 months after the vbackup is made).
>
> If there's a need for the vbackup to be on it's own media (for disaster
> recovery, archiving, consolidating physical media, etc.), the process would
> be:
>
> run regular backups (Full, Incremental, Differential) over time
>
> run periodic vbackups
>
> run a copy job from the vbackup to new media (a new pool)
Yes, that would work.
>
>
> [SNIP!]
>
> =>
> => Any comments?
>
> Thanks for all your work!
Thanks for using Bacula :-)
Kern
>
> Mark
>
>
> ----
> Mark Bergman voice: 215-662-7310
> mark.bergman AT uphs.upenn DOT edu fax: 215-614-0266
> System Administrator Section of Biomedical Image Analysis
> Department of Radiology University of Pennsylvania
> PGP Key: https://www.rad.upenn.edu/sbia/bergman
>
>
>
>
> The information contained in this e-mail message is intended only for the
> personal and confidential use of the recipient(s) named above. If the
> reader of this message is not the intended recipient or an agent
> responsible for delivering it to the intended recipient, you are hereby
> notified that you have received this document in error and that any review,
> dissemination, distribution, or copying of this message is strictly
> prohibited. If you have received this communication in error, please notify
> us immediately by e-mail, and delete the original message.
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
