ONTAP Discussions

Snapshot used space set to 0kb after SnapManager restore.

ivan_huter
4,840 Views

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?

NameDateUsedTotalStatus
sqlsnap__bia-chdc-sql10_12-25-2009_23.01.09__dailyDec 25 23:020 KB0 KBnormal
sqlsnap__bia-chdc-sql10_12-27-2009_10.40.38__dailyDec 27 10:410 KB0 KBnormal
sqlsnap__bia-chdc-sql10_12-28-2009_09.08.01__dailyDec 28 09:090 KB0 KBnormal
sqlsnap__bia-chdc-sql10_12-28-2009_09.21.55__dailyDec 28 09:220 KB0 KBnormal
sqlsnap__bia-chdc-sql10_12-29-2009_13.01.06__dailyDec 29 13:020 KB0 KBnormal
sqlsnap__bia-chdc-sql10_12-30-2009_09.18.55__dailyDec 30 09:190 KB0 KBnormal
sqlsnap__bia-chdc-sql10_12-31-2009_09.04.08__dailyDec 31 09:050 KB0 KBnormal
sqlsnap__bia-chdc-sql10_01-01-2010_12.41.52__dailyJan 01 12:420 KB0 KBnormal
CHNETAPP9(0118069635)_bia_data_mirror.2Jan 01 14:190 KB0 KBsnapmirror
rstsnap__bia-chdc-sql10_01-01-2010_14.21.42Jan 01 14:220 KB0 KBnormal
sqlsnap__bia-chdc-sql10_01-03-2010_10.19.17__dailyJan 03 10:200 KB0 KBnormal
@snapmir@{882D89EE-5731-4A7B-A8BD-3AB4C461C90A}Jan 03 12:390 KB0 KBnormal
@snapmir@{D7A34FEB-1DF6-4287-A754-9A5D9E1F6C77}Jan 03 12:440 KB0 KBnormal
CHNETAPP9(0118069635)_bia_data.7Jan 03 12:440 KB0 KBsnapmirror

9 REPLIES 9

p_liniger
4,840 Views

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
4,840 Views

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
4,840 Views

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
4,840 Views

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
4,840 Views

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
4,840 Views

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
4,840 Views

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
4,840 Views

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
4,840 Views

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.

Public