ONTAP Discussions

Snap Manager Exchange - Exchange 2010 SP1 DAG 2 Nodes - do not cleanup SANPINFO !

MARC_SAUTER
12,773 Views

Hi,

we have a Exchange 2010 SP1 DAG with 2 nodes

i do backup of DAG ... having Snapshots for 10days and utm (point in time revcovery) configured for 3 days.

But the files in SME_snapinfo are not deleted afeter 3 days - they only be delteted after 10days ... WHY ?

What is the funktion of the 3 days for pit ?   RetainUtmBackups 3 ??? Is this not the option not the cleanup for SNAPINFO ?

regards

marc

27 REPLIES 27

edgel
10,659 Views

Hi Marc, I am observing the same behavior.   We would like to reclaim this log space for our customers and are having to implement multiple backup groups with different log retention options as a workaround since SME will not clean these up in a single backup management group.   The release notes seem to indicate that this feature should work as of 6.0.2, but SME seems unable to reclaim the log space until the backup ages out using a single backup management group.  Have you opened a case on this?

hutchinson
10,903 Views

I am also experiencing similar issues, I thought the value was backups rather than days though?

radek_kubka
10,659 Views

Hi,

You can specify either the number of backups, or days.

Regards,
Radek

rmharwood
10,903 Views

Just caught this thread. I opened a support case on this exact issue a couple of months back and it was flagged as a known bug with ID 554340 (not publicly visible). The fix is due in the "next release" but I was told this is not scheduled until Q3.

Richard

hutchinson
10,903 Views

So whats the deal will it ever flush the logs in the sme_snapinfo folder? Is a work around to not use the NTFS hardlinks functionality?

rmharwood
10,904 Views

The logs get flushed according to the snapshot retention period, but SME seems to ignore the "point in time" / "up to the minute" retention. I don't think there is a workaround other than manually removing the log files from the appropriate snapinfo folder.

Richard

hutchinson
10,659 Views

So a workaround would be to create a script that clears the logs after a backup.

Surely up-to-the-minute restore would still be achievable (not in the netapp sense) by restoring the last snapshot then replaying the Exchange logs that had not been flushed?

rmharwood
10,659 Views

Yes, a script would work. We work around this by archiving to secondary every day and only keeping one day's worth on the primary. The restores are a little more complex but the amount of space used (/wasted) on logs is gone.

I have never understood the necessity to keep all of the logs AND keep all of the previous logs in snapshots. I agree that utm should still be possible by using just snapshots.

hutchinson
10,659 Views

I guess it is so that you can restore any particular minute in between the last few backups, which we dont need and can't turn off (another crazy NetApp bug!)

Not being overly familar with scripting this is going to be a nightmare trying to create a script which deletes the correct files without upsetting SME!

hutchinson
9,957 Views

Juist to clarify are you saying that if you set the -retaindays variable to 1 it will remove those saved logs from the sme_snapinfo directory as well as the actually snapshots themselves.

Message was edited by: Andrew Hutchinson Just confirmed this myself acutally

rmharwood
9,957 Views

Yes but if you need to restore from those backups you need to have them somewhere else, obviously, either copied to tape or to a snapvault secondary.

edgel
10,201 Views

One workaround I did find was to create another backup in a separate backup management group. This seems to wake up SME and delete to the number of SnapInfo folders specified in the UTM retention setting.

hutchinson
10,201 Views

So if for example if I had 5 backups throughout the day with UTM retention set to 1 day in the 'standard' backup group then ran a backup at the end of the day the same but in the 'daily' backup group, it would delete all UTM logs for the previous day?

hutchinson
10,200 Views

Right, I have spoken to NetApp support as well and they confirm there is no workaround except manually deleting the UTM logs within the SME folder.

I have now found a vbs script that can be scheduled to remove folders older than X amount of days.

Below will remove all folders in the location "E:\sme_snapinfo\EXCH_SERVER\SG_DATABASE" older than 1 day, i.e. if you ran it on the 23rd April 2012 it would delete all folders modified on the 21st April 2012 and earlier, it will also confirm the date of each delete with a confirmation box.

Option Explicit

Const intDaysOld = 1

Dim objFSO : Set objFSO = CreateObject("Scripting.FileSystemObject")

Dim objFolder : Set objFolder = objFSO.GetFolder("E:\sme_snapinfo\EXCH_SERVER\SG_DATABASE")

Dim objSubFolder

For Each objSubFolder In objFolder.SubFolders

'WScript.Echo objSubFolder.DateLastModified

If objSubFolder.DateLastModified < DateValue(Now() - intDaysOld) Then

WScript.Echo objSubFolder.DateLastModified

objSubFolder.Delete True

End If

Next

Below will do the same but without the confirmation box.

Option Explicit

Const intDaysOld = 1

Dim objFSO : Set objFSO = CreateObject("Scripting.FileSystemObject")

Dim objFolder : Set objFolder = objFSO.GetFolder("E:\sme_snapinfo\EXCH_SERVER\SG_DATABASE")

Dim objSubFolder

For Each objSubFolder In objFolder.SubFolders

If objSubFolder.DateLastModified < DateValue(Now() - intDaysOld) Then

objSubFolder.Delete True

End If

Next

This works great for me please use with caution though and test with a temp folder first!

edgel
10,201 Views

Hi Hutchinson,

Thanks for the script.   I am trying to determine if I can modify it to:

1) mount the backup snapshot in question

2) run eseutil /k to determine the required log sequence number for clean shutdown

3) dis-mount the snapshot, and delete only the logs older than that sequence number from within the SnapInfo folder of the active filesystem. 

This way, SME restores will still succeed as the SnapInfo folder will be present, but will contain the 2-3 logs I need to replay vs the 1000 or so logs I generated that day.   I may also be able to get the info I need from the SME backup manifest itself (need to look into that), but the point is that I want to delete only the logs I no longer need, and not the whole folder (since SME needs this for restore and to transition the restored .edb file from "dirty shutdown" to "clean shutdown" before mounting it.  

In the meantime, I am testing a post-processing script for SME that mounts the last backup and causes it to take all non-required logs (for clean shutdown) and move them into a sub-folder of the SnapInfo folder called "committed_logs".   Downside is that I have to remember to move the contents of all retained "committed_logs" folders back to original location if I want to perform UTM restores in SME, but for point in time and SMBR I can use SME natively without taking a huge space penalty and can use a modified version of your script to prune out the older ones.

I do hope the fix for this will be released soon.   Thanks.

edgel
9,515 Views

https://communities.netapp.com/thread/20445

Just wanted to document the rather painful workaround I am using to get my log retention down from over 1344 hours to a more manageable 322 hours (still only want 48 hours, but this is progress) using multiple backup groups.  

hutchinson
9,515 Views

Hi Edgel

I'm not sure I can help you any further, I have just accepted that I can only do UTM restores for the last few days. It certainly is annoying, I have also found that Snapshots older then the retaindays variable are not deleting so I have to delete them manually as well!

Thanks

hutchinson
9,515 Views

Edgel, the fact this script removes the XML file as you stated in the other post is probably my snapshots are not being deleted would you agree?

hutchinson
9,514 Views

Has anyone tried SME 6.0.4 to see if this is now resolved?

PERRYBARHAM
9,177 Views

I recently upgraded from 6.0.2 to 6.0.4 and my log folders are now being deleted according to UTM for my Exchange 2010 mailbox databases.  However, the UTM bug still exists for my Public Folder databases.  Opening an incident. 

Public