ArcServe R15 Backup to Disk Device using Dedupe

[Xoron]

We're planning our implementation of R15 and using Dedupe and local disk for on "onsite" backups (offsite will be to tape and sent out daily).

Ideally we'd have 2 disk devices, say DEDUPE01 and DEDUPE02 on a local disk on the file server. The backup jobs would run a full (dedupe) to each device for a 3 month cycle and then switch to the other device. When a device gets reused, it would format the device, and start a fresh new dedupe set.

Now here is my problem, the job scheduler in ArcServe is horrible. The best I can come up with is 2 jobs, each of which do a daily full backup M-F and exclude it from running for the 6 months of the year when I want the other job to run. The only problem with this setup is that I don't know how to schedule a "format job" to clean out the FSD.

Suggestions on how to make this setup work or maybe I'm missing something and there is a better way to go about this?

 

[Cyklops]

I understand from your configuration that you want to backup to disk media, keep it there for 6 Months and then overwrite the data. If this is the case why don't you create 1 disk device and purge the data from the dedupe device after 6 Months ? This way you'll have to configure it once and don't have to bother about formatting or erasing media. Also every backup made will remain for 6 Months and then purged from disk.

regards

 

[Xoron]

Cyklops,

Thanks for the reply.

That makes sense, but what happens if I do a massive data cleanup / move? Won't the dedupe job becoming inefficient, and my "compression ratios" be higher than necessary.

My thought process is that if I had two sets of 3 months, then the new "first index" would rezero everything, so my deltas would only be at a max 3 months old. The way you're suggesting, my "first index" would get infinitely older with no way to set a new "first index".

X

 

[Cyklops]

You are right that, when you make a massive data cleanup/move, you loose on the dedup figures. However, the same counts when you use the 3 months reusage of devices unless you do the data cleanup/move right before reformatting a dedup disk.
You are also right that your first index will become older when you start on a dedup device and let arcserve handle the purging. However when you create 2 seperate dedup devices that will hold data for 3 Months each then ARCServe will use the dedup feature on 2 entities that will not have any global dedup compression. When creating just one dedup disk the 'compression ratios' therefore will be higher.

 

[Xoron]

Cyklops,

I agree with you 100%, but I can budget for 2x dedupe space, it's harder to budget for 1x dedupe space with a potential for infinite growth.

Ideally the plan would consist of 4 jobs:
1. 3 months backup on Dev1
2. 3 months backup on Dev2
3. Format Dev1
4. Format Dev2

Scheduled to format the device right before the first time a new dedupe device is used. That way if I had to blow away a dedupe device at all, I still have 3 months of backups on the other device.

With only one dedupe device, and I had to do a format of it, I'm left with no onsite backups whatsoever. Not cool.


And while I'm at it, what's up with the crappy scheduler in the backup job setup? I mean I can schedule more granular jobs in crontab on a Unix system (days of the week, months of the year, specific day of the month, hours of the day). To setup a job to backup in Jan, Feb, Mar, July, Aug, Sept of every year requires so many jobs (or exclusions) to get it right in ArcServe.

X

 

[Cyklops]

If explained this way, you got a point configuring it the way you describe.
As for formatting the devices: use the Job Scheduler Wizard (to be found in the utilities) to format the DeDup Devices on a 3 Monthly basis using the ca_devmgr format command (the Syntax for this can be found on the command line reference in the ARCServe docs - in pfd format on the DVD). Strangely enough it is very easy to format dedup devices even if they hold large portions of data.

 

[Xoron]

Cyklops,

I saw the command line tape format, but from what I can see, it can only format actual tapes, not FSD devices. But I could be wrong.

X

 

[Cyklops]

as far as I know, FSD devices are seen as SCSI targets from CA_DEVMGR so you should be able to format them. It always worked with 'normal' FSD's, I was not able to test it out yet.
Regarding the Dedup devices: keep in mind that CA advises to keep the data and the indexes on separate volumes.

 

[Xoron]

Re: separating the indexes and data.

I think that's more for performance reasons. I'm not too concerned about that part, so I'm planning on putting both on the same volume.

I'll test out the formatting (ca_devmgr) to see if it'll work.