Phil Stracchino wrote:
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?
hi phil,
yes, that would be enough to meet my needs, but it would have a big
disadvantage
over my scheme, because duplicating media would take _hours_. we calculated,
that for our current data to be fully backuped, it would take more than
10 hours.
but thats one contra against alot of pros, i guess.
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.
yes, that right, but its a minor problem, because when the site burns
down, just a few more
hours could be saved if one could catch the changes between the two fulls.
Would this work for you until copy jobs are available?
yeah, but i dont think the changes in between the two fulls a worth such
an afford. so
i think i will just do two full backups. any idea when the features you
mention will
make it into a stable release ?
Thanks again for your comprehensive answer,
Philipp
-------------------------------------------------------
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
