01-19-2017 06:28 AM
Good day all,
i'm scannign a DSU storage for a puredisk service on a media server for NBU 188.8.131.52 on Linux Redhat 5.6.
I've found a lot of HISTORY/SEGMENTS/files very old, 4 or more years ago, occuping space.
The retention time for this solution is 2 weeks, for all the backups, so a retention and an history older than, let's say, 1 month just to be fair, is a waste of time.
How can i cleanup what's not more needed?
Why still it preserves all the segments, without compression or delete them automatically?
01-19-2017 12:08 PM - edited 01-19-2017 12:09 PM
Research how to list/determine whether any old backups reside on the storage unit. Someone may have accidentally run a backup with a long or inifinite retention, or an old SLP may have been stuck and then lost, or someone may have manually set a long or infinite retention of one or more backup images via the CLI. I think you might want to look at the bpimmedia command. If you get stuck using the CLI, come back and we'll see if we can help you.
If the above doesn't reveal anything... then you may have suffered some orphaned data. This rarely hapenned to some of the old versions of PureDisk and MSDP, but it could, and sometimes did happen. The only recourse was to open an official Support Case, and you would be given a tool and some commands to run.
Be quick though... official support for v184.108.40.206 ends in less than two weeks from now... on 1st Feb 2017.
01-19-2017 01:18 PM
thank you for the suggestion, i was not aware of the EOS next Feb, i need to upgrade then, asap.
However, the tool you suggested isn't present in my distribution, is the name right? nbbimmedia ?
Let me explain: i need to check and try to delete some of the files of the MSDP under DSU/data/ which are incremental numbers in the formato 10000.bin and 10000.bhd files.
Those are really old and part of the dedup means a bit weird, from so long time ago.
01-19-2017 02:08 PM - edited 01-19-2017 02:10 PM
The command which should help you identify inadvertent backup data retention is: bpimmedia
I would never advise manually deleting anything in the MSDP/PDDO folders unless instructed to do so by Veritas Support.
Yes, I know you want to get the space reclaimed, but we haven't proven why the old dedupe meta data is still there. This can only be confirmed and cleaned-up by two methods:
1) Identify inadvertent backup retention, expire these backup images, run image cleanup, run garbage collection and queue processing at least twice.
...and if the above does not work, then:
2) ...contact Veritas Support for analysis and check and fix for orphanned dedupe internal meta-data.
If you call Veritas Support first without having attempted step 1) first, then they will ask you to start at step 1) first.
01-19-2017 05:29 PM - edited 01-19-2017 05:29 PM
About the bpimmedia command:
...and see @Marianne's solution here, about how to expire images on disk:
How to reclaim deduplication storage space manually (PureDisk Storage Pool and NetBackup Media Server Deduplication Pool)
01-19-2017 10:51 PM
Tracking down orphaned data is a good idea, but bear in mind that expired data is only removed when there are no longer any current, unexpired backups referencing the old data.
Extract from Dedupe Guide:
Several factors affect the expected NetBackup deduplication capacity and usage
results, as follows:
■ Expired backups may not change the available size and the used size. An
expired backup may have no unique data segments. Therefore, the segments
remain valid for other backups.
01-19-2017 11:59 PM - edited 01-20-2017 12:01 AM
@Marianne raises a very good point, which I shall try to expand upon.
The fact that segment folders with names of "history/segments/2012-08-07" exist is not necessarily indicative of a problem. Your system might be running totally normally, i.e. there might not be any inadvertent image retention, nor any orphanned data.
The presence of folders named "history/segments/2012-08-07" might purely and solely be indicative that on those dates some backup was ingested and stored and added to the dedupe meta-data pool as "new" dedupe data.
If any and all subsequent backups since those data have ingested any data that this is the same as the backup data ingested around "2012-08-07" then some of the backup data from some of these subsequent backups over the last four/five years will have been deduping against the original first backup(s) that contained the backup data which had never been seen before at the time of the backups in 2012 - and thus those folders dated from "2012" actually represent the oldest copies of blocks which are still seen in recent backups.