Backup Exec 12 out of space.

[jmcleancjc]

Hi.

I have inherited the job of sorting out the school curriculum backups. We are running Backup Exec 12 ver 14 rev 1798.

As it stands the storage disk that is being used has rached full capacity. From what I have read there is a mechanism which should overwrite older backups to circumvent this from happening. Unfortunately, I believe this jobs that were originally created may not have been set up correctly as at first glance they all mostly show retention periods of 5 weeks.

I have since adjusted these jobs to what I consider to be more ideal, a full week every sunday with 4 week retention alongside daily differential backups weekdays to be retained for 1 week. 

The problem I am facing is that despite changing the jobs, I am still sitting at full capacity. I have read several pages and gone through to delete older backup sets (listed as containing several hundred GB's) yet my disk is still showing full.

I have explored the disk in question and see many .bkf files dating back which ideally need to be cleared to free up space. However I don't want to simply delete them as I don't know what impact this will have with Exec and it's catalogues.

Truth be told the whole think is quite a mess and wasn't managed particularly well and I want to correct it but obviously cannot afford to break any of the current (more recent backups). I'm sure most of the disk space is used up by duplicate backup content.

Any help is much appreciated as as it stands we're ongoing without any backup until it is resolved.

Regards
​James 

PS. Sorry if double post, can't seem to get these to post/show up.

[pkh]

Disk storage is now managed by DLM. You might want to read this blog and my article to understand how it works, especially the part about keeping the backup chain until a new recovery point is created. https://www-secure.symantec.com/connect/blogs/data-lifecycle-management-be-2012 https://www-secure.symantec.com/connect/articles/when-backup-sets-are-deleted-under-dlm You should not delete backup sets from the disk storage. This will create orphaned entries in the console. You should delete them from the console by going to the Storage tab, right-clicking on the backup sets and selecting delete.

[Steven_Moran]

Disk Storage in BE2012 is now handled by DLM, I'll assume that the post-er really means BE 12.

In the properties of your backup job(s), in the Destination section, you should be able to see the Media Set that the job is using.

Go to the Media Section, find the Media Set that the job(s) is/are using, and look at their properties.

We are looking for is the Overwrite Protection Period.  My guess is that it is set to some absurdly long value (like infinite). What is yours set to?

If you look inside your Media Sets, you will see an item for every piece of "Media" that BE has in its DB that is associated with that set. Since you are dealling with B2D, each item should represent a specific backup file in your Backup-to-Disk Folders that BE is writing backups into. You can think of them as virtual tapes that BE fills with backup data and can re-use if allowed to do so.

So here are some things to do:

1) Set the Overwrite Protection Period (OPP) of your Media Sets to a value you can live with, that also will meet your data retention obligations. This will immediately allow Backup Exec to start recycling the B2D files in that media set that were last written to beyond that OPP timeframe.

2) You could also "move" (associate, technically) some of your media into the Scratch Media set. Anything in that media set is intrinsicly overwritable and is usually where BE looks first when it needs more overwritable media. However, if your OPPs are still stupidly long, you will wind up back in the same situation. Another problem is identifying which media we should Scratch - what if a backup spans B2D files, and you Scratch part of a backup?

  After you complete step 1 (and give the DB some time to catch up, because it sounds like you might have a lot of B2D media), check out your media in their Media Sets again. Hopefully, you'll notice that some of the media has its info in blue text, and others in black. Blue text indicates that BE sees the media as overwritable/recyclable, while black text is not overwriteable (but may be still appendable). Media with blue text - in theory - should not have any backup jobs completed within the OPP for their Media Set, and can safely be Scratched.

Now, while these fixes will allow BE to resume backups, it won't free up disk space from the OS/File System perspective, as BE will just overwrite the existing content. If you need to free up disk space, then you should do something else.

Instead of moving old, overwriteable media to the Scratch Media set, move them to the Retired Media set. That is the only area in BE were we are allowed to delete media from the database. Take note of the Media Labels of the media - those are the actual names of the files on disk. My impression is that (for disk media only) Retiring the media will also delete the corresponding file on disk - but I might be mistaken. Either way, once the media has been retired, it is gone-gone as far as BE is concerned, so you can safely delete the corresponding files on disk (if BE didn't do it for you). I don't think I'd retire all of them, as BE will just start creating more files if it needs to. Better to leave Disk Media in place to save some effort in re-allocating disk space for new backups.

Let us know how it goes!

Steve Moran

[pkh]

I'll assume that the post-er really means BE 12.

Nope.  He said, "... ver 14 rev 1798."  Ver. 14 is BE 2012 and his disk storage is managed by DLM.  Media sets do not apply.

[Steven_Moran]

I missed that and spent a great deal of time typing!

[jmcleancjc]

Thanks for your input.

Yes i have checked and it appears that despite the retention settings that were originally configured (5 weeks) the OPP is infact set to infinite on -everything-.

So logically I am assuming that this would need to be set to match the corresponding desired retention period - as how I read this is that the OPP superseeds the retention period. Problem is, I can see the OPP for each media set but cannot see anywhere to change it.
The closest I have found is configuration and settings -> backup exec settings -> storage -> media protection overwrite level. This has been set to partial without prompt but im guessing this is the wrong place as no option explicity gives me an option to set OPP to X amount of time.




Before I lose my chain of thought due to distractions in the office, I also have a query regarding the full backup. Ultimately for me is to have a full backup run every friday while having a differential for mon,tues,wed,thurs. I have set the daily retention to 7 days and the weekly to 4 (so that by the time the 7th day is up and monday gets overwritten it will be present in the full backup - to make the daily media replaceable /rinse and repeat).

Now I set this up and it ran full backups for 3x servers and already my new disk is 75% full. What I would like to know is will the next week full backup be standalone or just an increment to the previous? I am probably not wording this correctly so let me try to expand:

Week 1 - Full backup x3 = 750GB total
Week 2 - Full backup x3 = 750GB(previous) + 750GB(new) = 1500GB total
Week 3 - Full backup x3 = 750GB(week1) + 750GB(week2) + 750GB(week3) = 2250GB total

Or

Will the difference (perhaps 50 GB of new data since last week over the course of the daily differential backups) be merged to the 1st week making week 2 = 800GB?

As it stands i stand to run out of disk space yet again already in week 2 depending on how the full backups work (I can get more storage but I just would like to know for ease of mind really).


 

[pkh]

OPP and OPL do not apply in the case of disk storage. Read the references in my previous comment.

[jmcleancjc]

Thank you again, I have modified all the jobs to run on a full week/daily differential with 2 week retention on the week and 1 hour retention on the day.

My disks are still full and I am yet to witness this DLM kick in to create some space out of the older backups. It kicks off tonight at 11pm so I will have to wait and see what happened.

edit: I'm now getting a "The requested media is not listed in the media index and could not be mounted. To add the media's catalog information to the disk-based catalogs, run an inventory operation on the media and resubmit the Catalog operation."

I'm reading two articles regarding this and neither are making too much sense, I'm not sure how to pinpoint what is missing - I assume it could be something DLM just removed (I finally got some space back now).

I tried: 4. On the right hand pane remove the check mark for "Use storage media-based catalogs."

Unforunately I am still getting this error on both storage disks.
 

[jmcleancjc]

Resolved in my own manner.

Closed.

[CraigV]

...since this is a public, community forum, there might be someone else who has had the same, or similar issue in future.

Please close this off properly by including HOW you fixed it for future reference...makes life easier that way.

Thanks!

[jmcleancjc · Accepted solution]

I basically added +4TB of storage and started from scratch instead of trying to 'patch up' the problems as the system was in total disarray.

Regards