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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users