Re: Snapshot used space set to 0kb after SnapManager restore.

ivan_huter · ‎2010-01-03

We take a daily snapshot of our volumes using SMSQL. Data and log files reside on separate volumes (one LUN per volume that contains data/ log file) - I don't think this is relevant, but I'd rather supply more than less information. Over weekend our DBs got loaded up with some data that required us to roll back to a previous backup. Restore was done with SMSQL. Everything went fine, but ever since we performed this restore I get strange values when observing used Snapshot space with the FilerView web interface (DataOnTap version 7.3.2). I used to be able to see the size of each snapshot, but that's not the case ever since we've performed restore. Below is the screenshot of data volume and list of snapshots. Anybody has any ideas why am I unable to see the snapshot used size?

Name	Date	Status
sqlsnap__bia-chdc-sql10_12-25-2009_23.01.09__daily	Dec 25 23:02	normal
sqlsnap__bia-chdc-sql10_12-27-2009_10.40.38__daily	Dec 27 10:41	normal
sqlsnap__bia-chdc-sql10_12-28-2009_09.08.01__daily	Dec 28 09:09	normal
sqlsnap__bia-chdc-sql10_12-28-2009_09.21.55__daily	Dec 28 09:22	normal
sqlsnap__bia-chdc-sql10_12-29-2009_13.01.06__daily	Dec 29 13:02	normal
sqlsnap__bia-chdc-sql10_12-30-2009_09.18.55__daily	Dec 30 09:19	normal
sqlsnap__bia-chdc-sql10_12-31-2009_09.04.08__daily	Dec 31 09:05	normal
sqlsnap__bia-chdc-sql10_01-01-2010_12.41.52__daily	Jan 01 12:42	normal
CHNETAPP9(0118069635)_bia_data_mirror.2	Jan 01 14:19	snapmirror
rstsnap__bia-chdc-sql10_01-01-2010_14.21.42	Jan 01 14:22	normal
sqlsnap__bia-chdc-sql10_01-03-2010_10.19.17__daily	Jan 03 10:20	normal
@snapmir@{882D89EE-5731-4A7B-A8BD-3AB4C461C90A}	Jan 03 12:39	normal
@snapmir@{D7A34FEB-1DF6-4287-A754-9A5D9E1F6C77}	Jan 03 12:44	normal
CHNETAPP9(0118069635)_bia_data.7	Jan 03 12:44	snapmirror

p_liniger · ‎2010-03-24

We have the same problem on one of our volumes. Okb Snapshots after snap restore.

We're running 7.2.6.1P7 on a FAS-3040. Any ideas?

Thanks in advance.

radek_kubka · ‎2010-03-24

A quickie - SMSQL does not use volume SnapRestore. It leverages LUN cloning instead to preserve all backup history, including snapshots taken after the recovery point, which would get deleted by a SnapRestore operation.

franja_schmid · ‎2010-03-24

are there also 0kb in filer> df -h ?

did you try to manually copy & delete data - snapshot - copy/delete other data - snapshot to the volume. Does anything change with the view?

p_liniger · ‎2010-03-24

Thanks for your answer Mr. Schmid

No. The "df -h" command shows me that 123GB are used for snapshots.

I've created some manual snapshots but didn't move/copy/delete any data because this volume is used in a productive esx environment. So there's alot of changing data.

The size of the manual snapshot is also 0kb.

fas-0002> snap list nfs_esx_lnx03
Volume nfs_esx_lnx03
working......

%/used       %/total date          name
---------- ---------- ------------ --------
0% ( 0%)    0% ( 0%) Mar 24 11:36 Test2
0% ( 0%)    0% ( 0%) Mar 24 10:22 TestSnap
0% ( 0%)    0% ( 0%) Mar 24 10:00 hourly.0
0% ( 0%)    0% ( 0%) Mar 24 08:00 hourly.1
0% ( 0%)    0% ( 0%) Mar 24 06:00 hourly.2
0% ( 0%)    0% ( 0%) Mar 24 04:00 hourly.3
0% ( 0%)    0% ( 0%) Mar 24 02:00 hourly.4
0% ( 0%)    0% ( 0%) Mar 24 00:00 hourly.5
0% ( 0%)    0% ( 0%) Mar 23 23:03 dfpm_base(fas0002_backup_esx.1015)conn1.0 (snapvault)
0% ( 0%)    0% ( 0%) Mar 23 22:00 hourly.6
0% ( 0%)    0% ( 0%) Mar 23 20:00 hourly.7
0% ( 0%)    0% ( 0%) Mar 23 18:00 hourly.8
0% ( 0%)    0% ( 0%) Mar 23 16:00 hourly.9
0% ( 0%)    0% ( 0%) Mar 23 14:00 hourly.10
0% ( 0%)    0% ( 0%) Mar 23 10:00 hourly.11
0% ( 0%)    0% ( 0%) Mar 23 08:00 hourly.12
0% ( 0%)    0% ( 0%) Mar 23 06:00 hourly.13

fas-0002> df -h

...

/vol/nfs_esx_lnx03/ 422GB 367GB 54GB 87% /vol/nfs_esx_lnx03/
/vol/nfs_esx_lnx03/.snapshot 227GB 123GB 103GB 54% /vol/nfs_esx_lnx03/.snapshot

....

franja_schmid · ‎2010-03-24

snap status <volume>?

we had temporary (november 2009) the same phenomenon with two customers of ours (with ontap 7.2.5.1) but couldn't find out what the problem was. in the meantime everything looks fine again...

p_liniger · ‎2010-03-24

Unfortunately the "snap status" command is not available on our filer (7.2.6.1P7).

So the problem is only about the displayed snapshot size? Will I be able to snap restore in case of data loss?

thanks for your help.

radek_kubka · ‎2010-03-24

It looks to me like some minor bug displaying incorrect snapshot size.

Looking at your naming convention I guess you're running ESX over NFS, correct? If that's the case you can always browse into your snapshots, check whether you see vmdk files & also do some test single VM drag-and-drop restore. Or if you have FlexClone license in place, you can clone a snap & mount it to ESX host for even more thorough testing.

Regards,

Radek

p_liniger · ‎2010-03-26

Thanks for your suggestions mr. kubka.

Fortunately, the displaying bug just went away.

We have a retention time of 24 hours on our ESX volumes and we think, that the problem solves itself with the deletion of the, in the restore process involved, snapshots.

ivan_huter · ‎2010-05-13

I figured what the problem was. I was 100% sure this was a bug. Since this wasn’t my burning issues I put this on a back burner and found out problem went away after a while. Then some time passed and I had a similar problem on a different volume. I then put two and two together and realized that I had this problem every time I rolled back some of my databases and created restore snapshots “rstsnap__”. Each time I restored DB from snapshot using SMSQL I would see this issue where snapshot size would get all jacked up (display 0K). After deleting restore snapshots “rstsnap__” problem was solved and I was able to see the accurate snapshot size.