Jump to content

On/Off Site Backup (on-site died)


Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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 by Guest
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...