Arcserv DB Pruning.. How to limit?

[gwichman]

When merging a tape, i can expand the sessions on that tape and see file by file what is backed up on that tape. However the next day, that info is gone. Still see the tape label and sessions. But can't get to the finer level of granularity of info of file by file info.

Why is this dissappearing so fast?

 

[poochie]

Because the job which was merged in the Database falls within the date set for Database pruning, the next time Database Pruning Job is done it will clear the merged data from the database. Adjust your Pruning days to be much more and the merge job will remain for you to use next day and so on.

This will definitely solve your problem

 

[Blogg]

Poochie,
Why then do CA advise against increasing the default 30 day database store?, whilst you are advising otherwise, I am not being smart just curious

 

[poochie]

This is exactly what I'm saying. If your database pruning is set to say 30 or 40 days, increase it and then perform the merge again. If the data is still not available the next day, this simple means that the merge job is older that the days you set for database pruning, in which case you'll need to increase it much more.

Get back to me if you still don't understand

Regards

 

[Blogg]

Yes, I understand, but if you increase the DB size performance is known to suffer (according to CA), I can see it could be beneficial to icrease the DB temporarily, but overall I'm of the opinion that if you do a merge and know the merge data is older than 30 days (default) then you should perform your restore immedialty (or pause the prune).
Just kicking stuff about....
Regards

 

[poochie]

I think we've got our wires crossed. I'm referring to Pruning Database records older than ..... Days. This feature can be changed in ARCserve Server Admin under the Database Engine Configuration Tab. I personally have increased this before and experienced NO Problems.

 

[wamason]

Poochie,

Soory to interject here, but blogg is actually is correct in his thoughts about temporarly stopping the pruning job for a day or two or just perform the restore immediately. You are also correct, it would just be a matter of choice as to which method to use. Personally speaking, if I merged a tape today and still needed the details for a retore tomorrow, I would put the prunung job on hold until tomorrow. Again, this ony MY two cents.

 

[poochie]

Ta for your 8 percent (giving you some credit). This would definitely be the best solution as a temporary measure.

Regards

 

[jabus]

Prune uses the date that the records were inserted into the database, not the date the backup was done. So if you merge in a tape, and your prune days were set to 30, then you have 30 days to restore those files.

 

[rmv]

hmmm this does not seem to be the case when I have merged tapes older than 30 days. As soon as the next Pruning Job occurs that data is gone.

 

[jabus]

Are you at the latest SP? Try merging an old set in, then kick off a merge manually to see if those records are removed. If so, then that is not the way it is supposed to work.

 

[Blogg]

Jabus, I too think you are incorrect here....sorry.

Blogg

 

[mspope]

Unless you really need to - why prune at all? I don't prune any records. I consider all my tapes as active and don't want to have to waste time merging tapes.

 

[speshalyst]

Guys,

I think we are going on a tangent here..

On the ARcserve server admin\configuraiton database tab

check if you have selected
"Delete Media-Related database Records ONLY when Pruning"

If so uncheck it...

Cheers
Speshalyst So it Shall be Written!
So it Shall be Done!!

 

[jabus]

Blogg,

I received that information from the L2 db development team.

Another cause could be the mergecat.exe program itself. There was a problem where it would merge the CAT file, but you could not see the details--only the directory structure. This was fixed in May.

 

[Stacy12]

just my two cents spoke to an arcserve support and while it is defaulted to 30 days you don't have to keep it set at that since we all have our policies on restoring information etc...that was what I was told my CA....I even interjected and explain that I was told specificaly by support before that 30 days was reccomended he said this was not the case due to other customers polices....

 

[jabus]

The size of the database is also a factor in the prune days. If you're database can easily manage 60 days worth of data, why not?

An FYI...for those in a Central DB environment, only have the primary server run the prune job.