Strange behavior on OST free space reclaim

[IXISBDA]

1 Caso. 2 MMS and 1 DR4000 by MMS.

I have two DR4000 in my two sites. One for backup to deduplicate (prod site) and other to duplicate these backups to rescue site.

So, these DR4000 must contain more or less the same datas. But my prod site DR4000 have 24% of free space then my rescue site DR4000 have only 2% now.

How backup exec reclaim free space on OST ?

I can't find a way to figure out where is the difference between space usage from DR4000 prod and rescue ?

If anybody can give me help.

[teiva-boy]

This has little to do with BackupExec, and more to do with your Dell DR4000 boxes.

Dedupe appliances follow the settings within the BackupApplication when it comes to Overwrite, Append, and retention settings.  The appliances have a clean up or garbage collection process that runs daily , weekly, etc; usually to some sort of schedule.

During the garbage cleaning, it scans the data, looking for the retention metadata.  If it finds something that that has reached its date, it gets removed from the appliance.

So make sure your retention policies are correctly set on your media sets, and manually initiate a clean-up (Also referred to as "Cleaner Schedule") on your appliances.  Refer to Dell's documentation on how to do that.

[IXISBDA]

Thx teiva-boy.

I know about the DR4000 cleaner schedule process. DR4000 appliance clean all obsolete data when a chunk is no more referenced. You said, datas stored in DR4000 by backupexec have a retention property setted (like a timeout lifetime)... into DR4000 ? or as I think the retention is always processed by BE and BE tell DR4000 to delete this or that data.

They are no retention policies setting on media sets when media is deduplication device (they are no media sets at all like tape media sets for example). The retention can be set just in backup job. This is the property "Keep for".

So. I set exactly the same value (8 Weeks) for :

- backup job from server files to deduplicate DR4000 A (prod site)

- duplicate job from source = previously job, to DR4000 B (rescue site)

Since april 2013 to september, space free on DR4000 are stables and since october to now the space free on DR4000 B fall (2 %)... then the space free on DR4000 A still stable (25 %).

I don't understand this behavior. If I risk an hypotesis, I think BE inform DR4000 A about end of retention of files and not inform correctly (or not at all) DR4000 B because the A is for backup and B is for duplicate.

note : I put the SP2 on end of august.

[IXISBDA]

So, free space come back after these operations :

1 - Inventory and catalog on DR4000 B

2 - Show backup sets for DR4000 B

3 - Some OLD (and hudge) backups are reappeared like by magic

4 - Delete old backups no longer needed

5 - Wait

6 - Wait again

7 - Restart 3 BE servers (1 CASO & 2 MMS)

8 - Wait

9 - Wait again

10 - tada... DR4000 B is in receding. Free space come back !

Moral of the story: Do not believe when you see BE backups sets, but think about inventory and catalog before. And be patient.

if it can help someone

[IXISBDA]

Finally, the problem is still occur.

I can't understand why DR4000 B have 7% of free space than the DR4000 A have 26 %.

Even with DLM mecanism the B applicance must have a little bit more than the A because the retention cleaning the oldest full for A and keep it for B (it's normal behavior to keep the chaining with differentials).

But the delta beetwen A and B are much greater than I can expect.Especially with deduplication on board.

I don't understand again why cleaner process on A device run severly hours each days than B device seem to run much fewer time... few minutes.

It's like the B device keep data no longer linked with BE catalog and obviously BE never inform it.

Is it a way to view the real content of an OST device with or without BE ? some tools ?