<[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? :-)) |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. 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. 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. Surely, there is still some way to go until this can be used in production, but the road should be more or less clear. Or maybe You were talking of something different? |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. 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... rgds, PMc ------------------------------------------------------------------------- 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
