Philipp Steinkrueger wrote:
> Okay, i'll try to explain my idea again:
>
> I have two primary goals:
>
> G1: Protect data against burn down of the autochanger location
> G2: Be able to restore any data anytime without inserting tapes into the
> autochanger
>
> I dont think there are many options for G1, you have to remove the tapes
> from the location and put there somewhere else.
>
> Now if it comes to G2 i am getting into trouble, because if i removed
> the tapes
> of the latest fullbackup from the autochanger to fullfull G1, i cannot
> restore
> the data without inserting the tapes again.
>
>
> With my scheme it would be possible to fullfill both G1 and G2:
>
> 1. Make fullbackup (A)
> 2. Differential Backups (B)
> 3. Next fullbackup (C)
>
> C now has to be removed form the site to fullfull G1
>
> 4. Differential Backups against A
>
> If i could make differential backups against A, which would,
> as you said, increase the amount of data to backup, i could
> restore any data anytime without inserting the latest Fullbackup,
> because the older fullbackup plus the latest differentials hold
> all the data needed, right ?
>
> And if the site burns down, i would still have the fullbackup C.
> With my current scheme, which is just:
>
> 1. Fullbackup (A)
> 2. Differential
> 3. Fullbackup (B), remove A from changer
> 4. Diffenrential
> ....
>
> i would of course loose more data, because all i had in case
> of a burndown would be fullbackup A.
>
>
> Thats my idea. If there is any other way to accomplish G1 and G2
> i would _love_ to hear about it...
Well, there are future features coming that will make much of this
easier, including the copy job (duplicate media), and the migration job
(migrate a job from disk to tape). These would allow you to:
1. Make full backup
2. Duplicate the media
3. Send the duplicate copy offsite
4. Continue with scheduled differentials and incrementals, duplicating
the media for each differential job and sending it offsite
I believe this would better meet your needs, yes?
In the interim, try the following for a workaround:
1. Make full backup, and remove it from the changer.
2. Make ANOTHER full backup.
Now, at this point, you have the problem that any differential you make
is going to miss the changes between the two. If you cannot be certain
the data did not change in between the two, and those changes are vital
to you, you can now get "in sync" by the following admittedly rather
lengthy procedure:
3. Remove the second FUll backup from the changer
4. Prune the volumes used for the second Full backup
5. Make a Differential backup and remove it from the changer
6. Re-insert the volumes from the second Full backup and bscan them
back into the catalog
You can now send that first full backup offsite, knowing that your first
differential has any changes between it and the second full, and that
all future differentials will be done against the second full. Then,
each time you make a new differential backup, you send the previous
differential offsite. You SHOULD always, at any time:
(1) Be able to do a full restore from media on hand;
(2) Be able to do a full restore up to the last-but-one differential
using ONLY offsite media, which is a more complete restore than
available under your scheme.
Would this work for you until copy jobs are available?
--
Phil Stracchino [EMAIL PROTECTED]
Renaissance Man, Unix generalist, Perl hacker
Mobile: 603-216-7037 Landline: 603-886-3518
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
