EVA 3000 and LUN / Snap Options

[jayjayjay]

Hi

Sitation

Server One
DAS Storage of 1TB Datda

Server two
SAN EVA Storage with LUN Presented

Backup Exec on Server Two pulling data from Server one and then putting it on the LUN on Server two - Lots of network traffic

Plan

Server 1 - To present LUN of 1.2TB and move DAS data to SAN LUN

We did think of presenting this LUN on Server 1 to Server two as Read Only - but this is not possible? IE it can only be RO on both?

Next option was to Snap Clone the LUN and then restore it to another LUN that is presented to Server 2?

Assuming this latter approach is best?@

What would the overhead be on the SAN for Snaping the 1TB every day? Overhead in terms of extra cache storage and also performance and duration to snap that data?

Can anyone think of any other functionality that we can leverage here?

The driver for this is to reduce backups across the network and to also reduce backup jobs.

[Sheldon Smith]

Like any EVA, the 3000 is not a file server, it is a *disk* server. Unless Server One and Server Two are cooperating on the SAN Storage file system, that is to say, clustered, a single LUN can't be shared. Unless of course, as you already discovered, it is read-only on both.

Assuming the snap copy only needs to exist for the duration of the backup job, consider using a snapSHOT instead of a snapCLONE. The storage usage will be less. How much less is impossible to predict, however you will probably find it is *significantly* less.

[jayjayjay]

Sheldon

Many thanks for that response

Indeed the requiremetn is to Snap it to another LUN and then let Backupexec perform the backup.

At a high level - differences between SnapCOPY and CLONE?....do you know roughly how long 1TB would take to do either? Our option in this case would be to snap it in one of these forms everynight but impact to the SAN would be key to know. Also when we snap using either clone or copy - will open files be ok? ie docs etc? basically is it done "online"?

[Sheldon Smith]

First, both provide a point-in-time (time "T0") image of the original LUN. If you were to backup from the original LUN, would open files be OK there? Whatever condition the original is in at the time of the snap, that's the condition of the result. Typically in the case of a database, at time "T-x" the database must be put into its backup mode state so all db files are consistent, at time "T0" then snap, and at time "T+y" take the db back to normal mode. Where amount of time "x" is the same regardless of using original LUN or a snap (prep time), the amount of time "y" can be measured in seconds.

Differences between Copy and Clone: A snapcopy is "thin" -- it just contains the original bits from the T0 time. Any reference to data unchanged since T0 comes transparently from the original. The *first* time something changes after T0, the original data is copied to the snapcopy. The snapcopy MUST reside in the same disk group as the parent. A snapCLONE is initially created the same as a snapcopy, but as quickly as the EVA can perform, all unchanged data is *also* copied to the snapclone. Whereas the snapcopy is always dependent on the parent to provide unmodified bits, a snapclone becomes an independent vdisk. A snapclone can be in a different disk group from the original.

Hope this helps.

-----
Don't forget to rate the usefulness/quality of any and all responses to your question(s).

[jayjayjay]

Sheldon

That is extremely helpful!

Finally [he says]
I just read the differences in Snaps in the Business Copy documentation

Snapshots - faster and will provide a FULL copy of all the data relatively faster. If we use this, we would snapshot the LUN in late afternoon and restore it on another LU and let backup software do its thing. Would be be able to backup as soon as we copy the snapshot to the new LUN? Just trying to think the drawbacks from snapshot perspective and if the snapshot that has recovered on another LUN still has a relationship and thus impact to the source data?

Mirror Clones - byte by byte LUN copy of the data with option to sync daily for updates

In this instance would Mirror Clone be better? The initial mirror clone would obv take a period of time - but the daily diffs wouldnt be that much. Means we have the data always there and can schedule the differential updates daily or hourly? Backups would be to tape so historic data would be safe guarded.

If you was in my position which would you go for? If you had to

- limit network traffic for backups
- allowing for faster restore off the SAN for files for everyday user requests
- allowing for LUN to be presented to backup server to remove the need for over-the-network backups.

[Sheldon Smith]

A snapclone presented to a host is a complete filesystem. A snapshot presented to a host is a complete filesystem *as far as the host can tell* which is all that matters.

With the Mirror Clone, you have one full copy of the source, which you periodically have to prepare, just like with the snapclone and snapshot, then fracture the mirror, present the mirror to the Backup Exec host, run backup, unpresent, resync mirror.

So, snapshot the LUN in late afternoon, present it to the backup host and let Backup Exec do its thing. Yes, the snapshot still has a relationship and thus impact to the source data. And with snapshots, it is a lot easier, and cheaper storage-wise, to have multiple differentials, like hourly.

It's late afternoon. I'm *guessing* the majority of the users have gone home, so any impact on the source volume will not be noticed.

You could also take several snapshots over the course of a day, with one being written to tape; the others just being nearline copies.

Hope this helps.

-----
Don't forget to rate the usefulness/quality of any and all responses to your question(s).

[jayjayjay]

Sheldon

Understood

Just trying to understand int his case why anyone would then want to do Mirrorclone?

What would be the benefit of a mirrorclone over snapshot based on what you have said?

If we use Snapshot - and backup exec runs it will still indirectly be affecting the source data? as the snapshop is a skeleton of the filesystem which is then referred to the source data? or is this not the case?

If we DO leverage snapshot - do we just do one everyday and then present that LUN to backup server and thats it? We get all our data backed up ?

[Sheldon Smith · Accepted solution]

A mirrorclone is vs. a snapclone. It depends on how long the copy exists before it needs to be refreshed (if ever). For example, making a copy for data mining, it may make more sense to use a mirrorclone, allowing to resync daily and then fracture back off. Presumably only a portion of the source is changing daily, so instead of doing a full copy daily to a snapclone, only the changes are copied as the mirror "catches up" to the original.

If you use a snapshot, the system indirectly *reads* some of the source data. It would not make any *changes* to the source. EVERYTHING is simply arrays of pointers. For logical block "x", if there has been no change since the creation of the snapshot, the snapshot points at the same physical disk segment as the source. If there *has* been any change, it points at its own physical disk segment.

Frequency of generation is up to you. Then present the LUN to backup server. All your data at the time of the generation is on it. Create a snap and present it to the backup server. Look at it.

Hope this helps.

-----
Don't forget to rate the usefulness/quality of any and all responses to your question(s) by applying points.

[jayjayjay]

Sheldon - Many thanks!!!

Will look at which best suits next week!!

You have been extremely helpful!

[Sheldon Smith]

"You have been extremely helpful!"

Then please assign points. Glad to have helped!