HPE EVA Storage

Multiple Snapshots kept for 5 days on EVA4400

 
SOLVED
Go to solution
Sam_Lees
Frequent Advisor

Multiple Snapshots kept for 5 days on EVA4400

Excuse my ignorance, I theoretically understand Business Copy for the EVA. However have not implemented it.

I am currently proposing a backup solution for a customer who has recently purchased an EVA with BC license.

We would like to implement a D2D backup strategy for with Business copy and are proposing to take a Snapshot of a 700GB file server daily, and keep each snapshot for 5 days.

Production LUN
File Server - 700GB

Daily rate of change - 5% - 35GB


Snap 1 - Mon - 35GB
Snap 2 - Tues - 35GB
Snap 3 - Wed - 35GB
Snap 4 - Thurs - 35GB
Snap 5 - Fri - 35GB

The snapshots will be presented to another server to provide a restore from disk point.

I have 3 questions on this process.

1, Is this possible or funtional

2, What is impact on Performance and capacity

3, What is the restore process if I need to to look at the files from a snapshot two day's ago.

Note, we will not be reverting the snapshot back to the production LUN. It will be presented to the backup server.

If you can advise a simpler way of staging and retaining backup/snapshots of simple file servers it would be appreciated.



10 REPLIES 10
Víctor Cespón
Honored Contributor

Re: Multiple Snapshots kept for 5 days on EVA4400

Some comments:

- A space-efficent snapshot stores all data that changes from the moment you create it to the moment you delete it. So the Monday snapshot, if you keep it until friday will need 35*5 GB.

- The snapshot is presented to a host and it appears as a copy of the 700 GB disk on that moment in time. When you read from the snapshot, a small part is read from the snapshot itself, and most part is read from the production vdisk. This can impact performance.

- You can create a snapshot, present it to backup server, make a copy on tape and delete it. Or you can keep the snapshots all the week. It's a trade-off between space and speed of restoration.
Sam_Lees
Frequent Advisor

Re: Multiple Snapshots kept for 5 days on EVA4400

Thank you for the quick response vcespon.

Are you saying that the monday snap will actually grow to 35GBx5 and also Tuesday will also grow to 35GBx5. Wed......Friday will also grow to 35GBx5? So each Snap could grow to 175GB and my total repository for snapshots would need to be 875GB.

I though the Monday Snap stopped growing when the Tuesday Snap was created ? and the max size of each of my Snap's would be the daily growth of 35GB.

Thanks
Sam_Lees
Frequent Advisor

Re: Multiple Snapshots kept for 5 days on EVA4400

In addition

If the Production LUN is writing to the 5 Snaps is this a significant overhead. I.e. not reccomended ?

It is a general file server, not an application datastore, so we may have to test is to see if there is a performance hit.
Víctor Cespón
Honored Contributor

Re: Multiple Snapshots kept for 5 days on EVA4400

A snapshot stores all the changes from the moment it's created onwards. So if you do not delete them, monday's snapshot will contain M+T+W+T+F, tuesday's T+W+T+F, wednesday's W+T+F, etc. So with your assumption of 35 GB per day, you'll need 15*35 GB.

Regarding performance, the snapshots work on "copy on write" mode. When a part of the vdisk is going to be written, it is copied to the snapshot. This is done for each snapshot, so it generates more writes. Also when reading from a snapshot, most part of the data has not changed, so it will be read from the parent vdisk.

Maybe you should use mirrorclones, that way you do a initial copy and then can stop the replica for some time, copy that instant state to tape and then resynchronize the disk with the original. The disadvantage is that it needs a vdisk as big as the original.
Sam_Lees
Frequent Advisor

Re: Multiple Snapshots kept for 5 days on EVA4400

Thank you again. The process is becoming much clearer.
Sheldon Smith
HPE Pro
Solution

Re: Multiple Snapshots kept for 5 days on EVA4400

It helps to understand what happens when the snap is created.

At the time of the snapshot, T(0) ("T-sub-zero"), the EVA creates an internal structure called a snapshot. Amongst other interesting fiddly bits, the snapshot consists of a list of pointers to the existing segments of the virtual disk. So, at T(0) plus moments, when the snapshot is "ready", we have two entities, the virtual disk and the snapshot, both pointing to the same physical locations in the disk group.

Then, at time T(0+i), something happens. Either a change is requested by the host(s) controlling the original virtual disk, or the snapshot is presented to a host which wants to make changes of its own. Problem is, they are sharing the same spot, segment(x). So the EVA performs a Copy on First Write:

1) locate a segment of free space in the disk group where the snapshot resides,
2) copy the contents of the original segment(x) to the newly allocated segment,
3) split the pointers of the virtual disk and the snapshot so now each entity is pointing to its own copy of segment(x), and finally
4) whatever change was about to take place is allowed to complete.
And the snapshot is now one segment big.

From that time on, when either the virtual disk or snapshot want to change segment(x), the change is just to its own copy of the segment. And the snapshot is *still* one segment big. As initial changes to other segments are requested between the virtual disk and the snapshot, the Copy on First Write process is repeated, and that snapshot grows.

The following day, at time T(0') ("T-sub-zero-prime"), the EVA creates a SECOND snapshot (call it "snapshot-prime"). And again, at T(0') plus moments, when snapshot' is "ready", we have two entities, the virtual disk and the snapshot, both pointing to the same physical locations in the disk group.

Moving on, at time T(0'+j), something happens. So the EVA performs a Copy on First Write for the shared segment, segment(y), between the virtual disk and snapshot'. At the same time, the EVA checks if segment(y) is still being shared between the virtual disk and the first snapshot. If so, those *also* have to be split apart.

And everytime a segment is to be changed, the EVA must first quickly determine if any snapshots are still pointing to the original virtual disk segment, and for any that still do, make the appropriate duplicates. For any given snapshot, this continues for the life of that snapshot. If a snapshot is deleted, the Copy on First Write check is still being made on every other snapshot of that virtual disk.

Things to remember:

* The snapshot will only grow as long as those first write copies are needed to be performed. Once either entity is modifying a previously copied segment, it will be modifying a segment already allocated to the entity.

* For a "well behaved" application, say a database, typical changes tend to be localized to areas of the file, with other portions being read-only (and therefore not yet duplicated).

So it is possible that some of that 5% change that happened in Wednesday's snap was to portions of the virtual disk that had previously changed after Monday's snap. Again, it depends on where the changes are occuring relative to the virtual disk and the various snapshots.
Worst case would be by the time Friday rolls around, 5% has changed in Thursday's snap, 10% in Wednesday's snap, 15% for Tuesday and 20% for Monday. 50% = 350 GB.
Best case, 5% has changed in Thursday's snap, 5% in Wednesday's snap, 5% for Tuesday and 5% for Monday. 20% = 140 GB.

Note: While I am an HPE Employee, all of my comments (whether noted or not), are my own and are not any official representation of the company

Accept or Kudo

shIVinator.
Valued Contributor

Re: Multiple Snapshots kept for 5 days on EVA4400

One very important item that seems to be missed is that the snapshots work in 2MB *chunks*, meaning that if a 4k block is written, 2MB is "copied on first write". Therefore from the application will record less change than what the array is seeing.

As the snap grows the performance of the production will be less impacted.

HP does not recommend having snaps around any longer than 12 hours.

Duane
Sheldon Smith
HPE Pro

Re: Multiple Snapshots kept for 5 days on EVA4400

"HP does not recommend having snaps around any longer than 12 hours."

I don't ever recall seeing that in *any* of the EVA Best Practices documents.

Note: While I am an HPE Employee, all of my comments (whether noted or not), are my own and are not any official representation of the company

Accept or Kudo

S. Boetticher
Regular Advisor

Re: Multiple Snapshots kept for 5 days on EVA4400

Can just say about our fileserver (W2K3, 500 Users, 1,2TB LUN): we use both software based VSS (shadow copy restore possibilities) and just snapshots (we run a sync before to flush the windows cache to get a quite good consistent snapshot, I don't know if you can use software VSS and hardware VSS together).

What we found (which can become very critical for you): Software VSS makes a snap every 2 hours from 7 a.m. to 7 p.m., the delta is saved on another LUN, the 64 maximum possible snaps in Windows uses a total of around 50GB, so no big changes on the server.
HOWEVER: a single Eva-Snap kept for 12 hours only is usually 400-500GB in size after the 12 hours. So, whatever is going on on our fileserver, tiny changes in windows creates large changes on EVA.

So, we decided to take an EVA snap every 12 hours (in case a virus or other bad things will destroy large parts of that big LUN) and keep it for 12,5 hours (to have only short time 2 Snaps, but always have at least 1 snap).
For recovery of deleted files or mistakenly wrongly modified files (standard user errors) we rely on Microsoft VSS restore previous version technology.
Additionally we do classic incremental/full/synthetic full backups each night to VTL plus tape.

So, if a user calls and needs a file or prevoius version back, we can give it to him quickly for up to around 2 weeks just from Windows.

if something bad happens, we have a snap not older than 12 hours (plus we do CA synchronous replication to a second EVA in another building for DR protection)

only if VSS can't help we access backup application to get old version back...

Hope this real life experience helps for your design...