Hello,
18.11.2009 06:52, Jim Barber wrote:
> Hi.
>
> A while ago I tried to set up a backup strategy where I defined three pools.
> An incremental pool; a full backup pool; and a copy pool.
>
> The idea was to run incremental backups forever (except for the first one
> that would be promoted to a full).
> Then at the end each week consolidate the incremental backups into a full
> backup using a VirtualFull job.
> Then take a copy of the full backup for off-site storage.
>
> When using a tape library, I could achieve incremental and virtual full
> backups okay.
> But I could not run the Copy job because it refused to run, complaining that
> the read storage is the same as the write storage.
>
> I looked at the code for migrate.c and compared it to vbackup.c since both
> have similar concepts.
> I wanted to see why the virtual backup works and the copy won't.
> I found identical code in both, except in the vbackup.c the particular check
> that fails for migrate.c has been wrapped in #ifdef to remove it.
> Also a FIXME comment is there saying that instead it should just verify that
> the pools are different.
>
> Below is a patch to migrate.c to do the same thing as vbackup.c does.
> Is this a feasible patch?
Looks like it - if you tested it, and it works correctly. Don't forget
to test with only one drive available, in that case the job should
fail with a reasonable error message... and it might be better to
patch against the most current git version.
> Would there be any chance of this working its way into the official Bacula
> source? Or will it cause problems?
I suppose so. You should present the patch (which is *really* simply)
to bacula-devel, so the regular developers can think about it.
Actually, given the comments and the #ifdef situation, I assume the
idea was considered, tested, and then disabled for good reasons, but
with some discussion, and even a regression test (hint :-) Kern et al
might reconsider it.
I guess there might be some more work needed, but that's a discussion
for -devel.
Cheers,
Arno
> --- bacula-3.0.3.orig/src/dird/migrate.c
> +++ bacula-3.0.3/src/dird/migrate.c
> @@ -350,11 +350,14 @@
> Dmsg2(dbglevel, "Read store=%s, write store=%s\n",
> ((STORE *)jcr->rstorage->first())->name(),
> ((STORE *)jcr->wstorage->first())->name());
> + /* ***FIXME*** we really should simply verify that the pools are
> different */
> +#ifdef xxx
> if (((STORE *)jcr->rstorage->first())->name() == ((STORE
> *)jcr->wstorage->first())->name()) {
> Jmsg(jcr, M_FATAL, 0, _("Read storage \"%s\" same as write
> storage.\n"),
> ((STORE *)jcr->rstorage->first())->name());
> return false;
> }
> +#endif
> if (!start_storage_daemon_job(jcr, jcr->rstorage, jcr->wstorage,
> /*send_bsr*/true)) {
> return false;
> }
>
> At the moment I have a really badly hacked up configuration to try and
> achieve what I want by using each drive in the library independently.
> It is complicated and messy with lots of work arounds for various scenarios.
> If the above patch is okay then things become much simpler.
>
> Regards,
>
--
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
