Disk backup set questions

[blm14]

So, a little background first:

 

- I back up about 120 desktops, about 50% mac and 50% windows

- Til now we've used one script per client and one file backup set per client

- Every time I speak to retrospect they tell me I should be using disk backup sets and so I wish to switch over

- Hardware: P4, 8Gb RAM, 75GB local drive, with 2TB external ultascsi RAID-5 and DLT-S4 superloader tape library. RAID is divided into two logical partitions of 1TB each. I have two of these setups, except only one machine has the DLT-S4.

- Backups run from 7pm until 8:15am on weekdays (and all day on weekends) so as to avoid interfering with user experience (some of these machines are old and slow, and the retrospect client actually can slow some of them down a lot)

- Because of federal regulations, I cannot use grooming. Client machine host patient data and HIPAA rules require storage of ALL electronic patient record data for minimum 8 years. So instead I wait for RAID to fill and then dump entire contents to tapes.

 

 

Here is my concern about disk backup sets:

 

- Right now I have 8 execution units. If I make one disk backup set per drive, retrospect will only be able to ever use TWO of them because it can only be writing one client to the set at a time. I'm concerned this will drastically decrease utilization

- If I decide to divide into TWO backup sets per RAID then I can at least use half my execution units but then I may end up in a state where one disk backup set fills first and I have to dump to tape before drive utilization is 100%.

- Catalog files are one-per-disk backup set rather than one-per-file backup set, so corruption of config files or catalog could lead to entire disk set loss.

 

Really what would be perfect is if retrospect allowed me to write multiple clients to the same disk backup set at once. Thoughts?

[Mayoff]

Using the disk set is basically the same as writing to a file set. Most of the rules are the same.

 

Disk sets give you the ability to restore or transfer data from them even when a backup is still running. Disk sets store data in smaller data chunks instead of one giant file.

 

If you want 8 Disk sets, you should be able to backup 8 clients at the same time.

 

Disk space limitations are the same as you had with file backup sets.

[mauricev]

Quote:

---

I back up about 120 desktops, about 50% mac and 50% windows

- Til now we've used one script per client and one file backup set per client

 

---

 

120 scripts?

 

Quote:

---

Right now I have 8 execution units. If I make one disk backup set per drive, retrospect will only be able to ever use TWO of them because it can only be writing one client to the set at a time. I'm concerned this will drastically decrease utilization

 

---

 

With disk sets, you'd want a single disk set per execution unit. That would let you backup 8 computers simultaneously. But depending on how much data are on these systems, I suspect you could get by with 4 (~30 computers per set).

 

Quote:

---

RAID is divided into two logical partitions of 1TB each. I have two of these setups, except only one machine has the DLT-S4.

 

---

 

Why two partition and why two servers? You don't have that many clients. And I would suggest combining the RAID into one partition because it makes rebuilding catalogs easier and you might have to do that from time to time.

 

Quote:

---

 

- Because of federal regulations, I cannot use grooming. Client machine host patient data and HIPAA rules require storage of ALL electronic patient record data for minimum 8 years. So instead I wait for RAID to fill and then dump entire contents to tapes.

 

---

 

What happens if the RAID gets hosed before it gets written to tape? Losing data to grooming is probably not that likely, either. The file on the client has to change before it can be groomed out. If you are not filling up the RAID that quickly, then you could schedule dumps to tape before a groom occurs. If you have enough space, then grooming won't occur until it reaches the schedule, which you can set. If you set it to keep, say, 30 snapshots, that would keep things around for a month. Plenty of time to archive to tape.

 

If you don't running grooming at all, what happens after the RAID fills? Do you start fresh? That's a lot of extra work for a fresh backup and what does the backup do while the RAID is filled and you are dumping to tape? Also, I'm assuming you're doing at least two tape sets (one onsite and the other offsite), which would double the time it takes to backup after the RAID fills.

 

BTW, I can't find any reference to 8 years in HIPPA, only 6.

[blm14]

RE: 120 scripts. Yup! I didnt set it up that way though and I've since changed it (see below)

 

RE: two partitions - this is the RAID manufacturer's suggested configuration. I agree it's kind of goofy but we used to have a single one and it did cause weird behavior with the controller so we put two partitions and the problem went away. <shrug>

 

RE: RAID hosing (heh) - that's one of the reasons that we have two identical servers, so in case one of the RAIDs dies we at least have the other one. Plus anyone who's ever had problems with AES-CPP or ELEM-CPP will understand that it's nice to have a second instance if one has problems so that you can at least continue to be backing people up.

 

About when the RAIDs fill up - yet another reason why it's nice to have the two instances. Once one of them reaches about 90% capacity, I start backing one up to tape while the other still runs and then once that one finishes, I turn it back on for backups and then dump the second to tape. Yes, during those couple of days there's only one instance running but I haven't really found a way around that short of 3 instances.

 

RE: HIPAA - my employer stipulates 8 years, not sure why they chose more than the federal reg, but I'm sure our CIO had a good reason.

 

At any rate I ultimately ended up going with what you suggested - 8 execution units and 8 total disk backups sets, 4 per RAID. But now I just have one script per backup set and this seems to be working very well with one exception: I now have no real easy way to tell when each client has last been backed up:

 

- ReportWatcher (in addition to being "not supported" - LAME!!!), is volume-level and appears to have multiple entries even per volume sometimes and anyways isn't part of retrospect itself

 

- The "backup report" screen which seems really buggy. For instance on one of the servers it has no dates under a bunch of the clients that actually have been backed up many times.