Kern Sibbald wrote: > On Monday 22 June 2009 21:38:01 Phil Stracchino wrote: >> On this subject, now that I have a current dev environment again, >> roughly what would be involved and what would have to be borne in mine >> if I were to enveavor to extend the Copy and Migration features to work >> between pools owned by different SDs? I'm still trying to get caught up >> on a lot of things and haven't looked in detail at the current >> implementation yet. > > Doing a Copy or a Migration to another SD is a bit difficult because it > implies some sort of SD -> SD communication, which we don't currently have. > > Can you be a bit more specific about what you would like to implement and for > what reason. If you want to take volumes offsite, then we should talk about > having some offsite functionality (or extending the few features we currently > have) or we should talk about an Archive functionality, which can also be > used for taking tapes or volumes offsite. > > If you want the feature for some other reason, I would like to understand the > reason first because that to a large extent determines what kind of a feature > to implement.
Well, the reasoning is basically quite straightforward. At present, the restriction of copies and migrations to a single SD means, as I understand it, that they are /de facto/ restricted to a single host. This means that one cannot, for example, do all routine nightly backups to a large disk farm, then later copy (for example) Full and Differential backups to a tape library attached to a different host which may be elsewhere in the building or even in a different building; or, for that matter, copy them to another disk farm in another building for redundancy in a disaster-recovery scenario. The weakness of backing up to disk is that it leaves your entire backup strategy vulnerable to a failure that takes down the disk farm. However, for nightly backups in a large facility, tape may be too slow to back up in real time. The obvious solution to this dichotomy is to back up to disk for speed, then later copy or migrate to tape, or copy to a separate disk farm on entirely separate hardware, for redundancy and safety. In the latter case, having the second disk farm on the same host where it can be controlled by the same SD defeats the point of the exercise. In the former, it may be undesirable or infeasible to have the tape robots attached to the same hosts as the disk farm. (My own personal situation is a good example of the latter: My tape drive would not tolerate the temperature and humidity fluctuations in the deckhouse where my server rack is, but the server rack is too noisy to move inside where my workstation is.) At least partial technological solutions exist to most of these issues, of course. SANs potentially offer at least a partial solution to the disk-farm issue, by allowing the SD to access multiple disk farms that are in physically separate locations even though attached to the same network. Even so,in the event of a failure that affects the SD performing the backups, the failed SD needs to be rebuilt before anything else can be restored. iSCSI possibly offers a solution to remote tape libraries, though it means the tape libraries and the host operating systems in question must have iSCSI support (and I don't know how well supported tape libraries are over iSCSI). It seems to me that may of these issues could be dramatically simplified, particularly for small shops, if jobs could be easily copied or migrated to a remote SD on a physically separate host. It allows physical separation of different storage devices, and allows for a much greater degree of redundancy in the overall backup system, with a correspondingly greater degree of disaster survivability, as it would allow a distributed backup system with multiple directors and SDs in which each client was normally backed up by a specified Director to a specified SD, but in case of a disaster, any client could be restored by any Director from any SD that has a copy of its backups. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 [email protected] [email protected] [email protected] Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
