-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Peter Much wrote:
> <[EMAIL PROTECTED]> aka Ryan Novosielski schrieb
> mit Datum Fri, 08 Feb 2008 10:12:30 -0500 in m2n.bacula.users:
>
> |some of your documentation as it somewhat
> |looks like you will be writing some
>
> Ahh, You sure of that?
> :-))
Maybe not, but you at least bothered to explain the problem well enough
to indicate you had a plan. That's a lot more than I can sometimes even
say of my own projects. :-P
> |To the technical points you discuss, you will discover that tape
> |mirroring is a problem, as currently choosing which media from which to
> |restore is not something that would work with Bacula the way things are
> |now.
>
> Hm, I'm not sure if I get Your point.
> As far as I see it does already work, it is only not yet
> supported or present in the configuration options etc.etc.
> Actually Your post inspired me to experiment a bit, and (besides
> finding another bug in the migration code - patch will follow)
> I could create identical mirrors of already completed backup jobs,
> and move them from storage to storage.
Really? How is this done? My understanding is that this was not
currently possible, at least not inside the software. Sure, you could
duplicate the tape itself so it was identical. In that case, both tapes
would be identical and Bacula would not be able to tell them apart,
which might be OK.
> Restore is not my concern, because I would direct such a mirror
> into a Pool with "CatalogFiles=no", so there will be no restore
> from it.
Fair enough. What is the rationale behind that?
> In the event that the primary backup will get lost/destroyed,
> that media could be replaced and the mirror migrated back to
> the new media - this step will automatically (actually
> as a side-effect) recreate the filelists in the catalog.
Is that definitely the case? That sounds more like using bscan than a
migration job. Can it be migrated without catalog information?
> Surely, there is still some way to go until this can be used
> in production, but the road should be more or less clear.
Have you been reading the code, and that's why you know this is in
there, or are you using a currently documented procedure in the current
version?
> Or maybe You were talking of something different?
Possibly. Let's find out. :)
> |You can run two backups, but for some places this is not compliant
> |with policy, as the backups will by definition NOT be identical.
>
> Yes, and doing two backups has another tradeoff: it puts extra load
> on the clients.
> The good solutions are either "stream-duplication", so that the
> backup data flow from the client goes immediately to two tapedrives
> (usually in different buildings and attached via SAN). This is
> the most effective method, but I think it is a lot of work to bring
> this into Bacula: an FD would have to talk to two SD simultanously.
There are plans for that as I understand it. There have been discussed
problems about how to or whether to catalog both. I suppose if only one
was cataloged, this problem goes away. When I think about it now, I see
the cataloging on a second tape (or two copies of such a catalog anyhow)
to be unnecessary, but I may be missing something.
> The other solution is to copy the backup after it is done. Here the
> disadvantage would be that one needs additional tapedrive ressources:
> not twice, but three times as much as for a single backup (taken
> that the tape throughput is fully exhausted). But this can be avoided
> with the disk staging.
> And this approach is already present in the Bacula code, and I would
> think it is quite functional.
> Surely those configurations are complicated - but those of the
> commercial solutions (the big ones, not the SMB-targeted) are not
> much less complicated.
>
> So my biggest concern is not how to do it. My biggest concern is:
> how good does Bacula handle severe concurrent activity? When doing
> backup to disk to tape, there should be at least 8 concurrent jobs
> on a disk storage object, and they should do something sensible...
Are you talking about the case of 8 individual concurrent jobs running,
or one job running and then subsequently splitting it somehow into a
number of copies (either manually copying them or some sort of migration
trick, etc.)?
- --
---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II
|$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922)
\__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHr8MSmb+gadEcsb4RAtJsAJ9g/S2DY6pZVf5jMjlzt38iw8z4xgCdFdXJ
tSht3DaKsvO+X/V/LoDNQ10=
=lUdU
-----END PGP SIGNATURE-----
begin:vcard
fn:Ryan Novosielski
n:Novosielski;Ryan
org:UMDNJ;IST/AST
adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103
email;internet:[EMAIL PROTECTED]
title:Systems Programmer III
tel;work:(973) 972-0922
tel;fax:(973) 972-7412
tel;pager:(866) 20-UMDNJ
x-mozilla-html:FALSE
version:2.1
end:vcard
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
