disegno Posted November 16, 2009 Report Share Posted November 16, 2009 Hi, we have the following 2 backup sets for archiving old jobs (removable 500GB drives): Archive HD Backup Set (on-site) + HD-01 + HD-02 Archive HD-B Backup Set (off-site) + HD-01B + HD-02B Today, the drive HD-01 died, and I'm wanting to bring across the data from HD-01B to a new drive and effectively have it as HD-01. 1. Will copying the data file from HD-01B to a new HD-01 work? 2. Will cloning HD-01B and then renaming clone to HD-01 work? Or is it not that simple...? Regards, Christiaan Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 16, 2009 Report Share Posted November 16, 2009 Christiaan, People often use the terms "Archive", "Backup Set", "Members", "Duplicate Copies", etc., interchangeably and incorrectly. It's not possible to answer your question without knowing exactly what your question is. (1) You say that you have an "Archive HD Backup Set" on site and an "Archive HD-B Backup Set" offsite. If, in fact, these are "backup sets", what type are they? File? Disk? Are HD-01 and HD-02 members of that backup set? If so, then their names won't be "HD-01" and "HD-02". (2) Or, are HD-01 and HD-02 single members of two different backup sets? (3) Exactly how did you create the HD-01B and HD-02B items? Are they members of a different backup set? If so, what type is that backup set? (4) Or, are you confusing "Duplicate / Copy" items with backups? Russ Quote Link to comment Share on other sites More sharing options...
disegno Posted November 16, 2009 Author Report Share Posted November 16, 2009 Sorry, here are the details... They are both Disk based backup sets, spanning 2 x 500GB HD's each. Backup Sets are: Archive A (on-site) Archive B (off-site) Members are: 1-Archive A 2-Archive A 1-Archive B 2-Archive B 1-Archive A is the disk that died. The backup sets were made independently of each other, so we would backup using Archive A and then do the same backup to Archive B to be taken off-site. Thinking about it, perhaps this isn't the best method, for precisely this reason - what to do when one member dies? Perhaps it'd be better to maintain the one backup set, and clone the members for the off-site backups? Then if an on-site drive dies, we can clone back to a new drive and continue as if nothing happened? Regards, Christiaan Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 16, 2009 Report Share Posted November 16, 2009 (edited) The members are a set, and go together. If one member of a set dies, the files on that member are lost. Note that, with the procedure you are using (two successive backups to different backup sets), the backup sets won't be the same if files change in the interim. May not be an issue with you. You need to bring the offsite set in, clone it, and use it. I would suggest something like SuperDuper! to do the cloning. There's a problem with doing clones of disk backup sets. Specifically, Retrospect tries very hard to avoid overwriting your backup data, and it is very paranoid. With disk backup sets, it uses the volume ID and other stuff to identify the member, and will know the difference between a clone and the original member. All clones are not created equal. Retrospect 8 is improved in this aspect, because it stores a sequence of .rdb files (600 MB each, I believe) in a folder, that would do what you want. Perhaps it'd be better to maintain the one backup set, and clone the members for the off-site backups? Then if an on-site drive dies, we can clone back to a new drive and continue as if nothing happened? That should work, providing that the clones are good. Another approach, which would create instantaneous perfect copies, would be to create a RAID 1 mirror for each volume, then split the mirror after the backup is done (with the volumes unmounted so that there isn't anything active). That's the way that sysadmins have, for years, made instantaneous copies of a live server volume without taking the server down. There's a white paper at the SoftRAID site (www.softraid.com) explaining the technique. We do that for our server's boot volume before making any software changes. It's a little more complex than that if you do it on a boot volume that isn't unmounted, because you have to stop some services (mail, etc.) to ensure self-consistent databases, etc., on the split mirror volume. Also, if you do it on the boot volume, you also have to turn off Retrospect's backup schedule or else, when you boot from the volume again, lots of missed backups will fire up, right during a crisis when you are trying to get the server back on the air, etc. Russ Edited November 16, 2009 by Guest Quote Link to comment Share on other sites More sharing options...
disegno Posted November 17, 2009 Author Report Share Posted November 17, 2009 We use Retrospect 8 on our server, but this is a stand-alone older machine purely for archiving old jobs (going back about 10 years). So, using Retrospect 6, would the following work? 1. Purchase 2 x 2TB drives (for future capacity requirements) 2. Have the 2 drives set-up as a RAID 1 mirror 3. Move/migrate our Retrospect data to the new RAID drives 4. We'd then break the RAID and have an on-site and off-site copy we could use It's point 3 I'm not sure about, moving the 2 x 500GB drives of data to the new 2TB drive. Is this possible? Regards, Christiaan Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 17, 2009 Report Share Posted November 17, 2009 It all depends on what the architecture of the Retrospect 6 machine is. On Intel, Retrospect 6 runs emulated under Rosetta, and Retrospect 6 has the older Carbon API. I think that there are some limits that you might hit. As for point 3, sure. Just do a Transfer to the new backup set on the big drives. Again, though, there may be some limits that you might hit. I think that there are some posts in this forum about hitting those limits. I only back up to tape, so I don't see those issues, but others might be able to comment. Now that the big volume bug (>= 8 TB) with Retrospect 8 has been fixed, there aren't those limits with Retrospect 8. As for continuing to use Retrospect 6, note that Retrospect 8 cannot, at present, read backup sets made by older versions of the program. Who knows when (if?) that capability will be added. Remember, it's almost a year since the program was announced, and there isn't even a manual. There is no perfect solution. Russ Quote Link to comment Share on other sites More sharing options...
disegno Posted November 17, 2009 Author Report Share Posted November 17, 2009 Thanks, we'll try the transfer (I'll look into any limits as suggested) - it's running v6 on a dual G4 with all sorts of different tape drives and old DVD media attached. Hence we're reluctant to upgrade if it continues to work... v8 we run using LTO-4 tapes for all "current/live" work and data - but have hit other issues there as well (lack of speed backing up clients mainly). Thanks again, Christiaan Quote Link to comment Share on other sites More sharing options...
disegno Posted November 17, 2009 Author Report Share Posted November 17, 2009 Yes, looks like there is a 1TB limitation on hard drives... yes, v8 removes this, but it can't read v6 backup sets, so I can't transfer the backup set to larger drives under v8 either... Looks like I'll be buying 4 x 1 TB drives instead. Christiaan Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 17, 2009 Report Share Posted November 17, 2009 Consider getting the 2 TB drives and formatting them as 2 x 1 TB volumes. That way, when you move forward, you will have the big drives. Russ Quote Link to comment Share on other sites More sharing options...
disegno Posted November 17, 2009 Author Report Share Posted November 17, 2009 This will still work with the RAID 1 mirror for each drive? Quote Link to comment Share on other sites More sharing options...
rhwalker Posted November 17, 2009 Report Share Posted November 17, 2009 RAID 1 (and all RAID) mirrors volumes, not drives. I know that SoftRAID can handle it (we use SoftRAID), don't know about Apple's RAID. Simply FYI, in our xServe, we layer RAID 1 on top of RAID 5 to handle two situations: (1) failure of the Apple Hardware RAID card (been there, done that); and (2) for adding a RAID 1 volume to the RAID 1 mix for our boot volume, to permit splitting off a member of the RAID 1 mirror prior to doing software updates in case things go badly (been there, done that, too). Russ Quote Link to comment Share on other sites More sharing options...
disegno Posted November 17, 2009 Author Report Share Posted November 17, 2009 OK, thanks - for simplicity's sake, we may stick with the 1TB drives (a 2008/9 archive and a 2010/11 archive or similar). In the future, (when it's supported) we may look at transferring across to v8 on our xServe with larger drives, but by then there may be other options as well... we've also got about 2.5TB of various DAT tapes and DVD's that would be great to consolidate at some point. Thanks again for all your input. Christiaan Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.