NDMP - how does it handle open files?

c.j.hund

ADSM.ORG Senior Member
Joined
Jun 22, 2005
Messages
247
Reaction score
4
Points
0
Website
Visit site
PREDATAR Control23

Hi all,

I have a customer whos #1 concern is open file support. I know NDMP backups are snapshots, but is that truly giving us something similar to OFS on the Windows client side? If a file on the NETAPP device is open when the NDMP backups runs, how is that file going to look if it's ever needed for restore?

Sincere thanks,
C.J.
 
PREDATAR Control23

Hi,

it depends - what kind of files (in term of "what is the protocol used for accessing the data on NetApp? BlockLevel - iSCSI or FC or FileLevel - CIFS/NFS) are we talking about?

1) File level - CIFS/NFS - NetApp is the "master of the filesystem" - clients writing to / changing the files have to wait for confirmation from NetApp that their write/modification is done (so there is no situation where clients things data is written but it is somewhere in the cache). File locking is for clients (so one cannot modify/overwrite others locked files) - not for NetApp itself. When the snapshot is taken, all files in the snapshot are flat and closed. This does NOT mean they are consistent (from application point of view) - can imagine situation where I copy huge file to the system and take snapshot in the middle - in that case I have half of the file in the snapshot ....
There is no way of doing "more consistent" snapshot of file data.
2) block level - FC/iSCSI - here the NetApp does not know anything about blocks being written in the LUNs. Server/application may issue write IO but this does not need to be done on the NetApp (yet) - it may stay in the server buffers/queues/cache - whatever - and wait for "being committed".
In this case you can use NetApp's SnapDrive for creating the OS-level consistent backup (simpy said - snapshots taken this way do not need chkdsk/fsck) or SnapManager for XYZ to have consistent backups from the application point of view (MSSQL DB can be attached without repairing)

So .. What is your case?

Harry
 
PREDATAR Control23

Thanks, Harry.

I'm still researching what will work best for this client, but I know that they think block level/standard NDMP backups to tape is the direction they want to go. There wouldn't be any mounted filesystems on either a linux or a Wintel box where the backup would be taken (that's been discussed and ruled out for various reasons). Access would be from the TSM server to the Netapp devices. It seems like what you described above ties into "snapdiff". Is that correct? It's a bit confusing from what's out there on the IBM web sites, but snapdiff seems like the best solution.

Thank you,
C.J.
 
PREDATAR Control23

Hi,

so it seems (correct me if I am wrong) the customer is using NetApp as a NAS device (CIFS/NFS), where clients are accessing shares and exports - which are accessible from TSM server as well.
Now you have two options
a) use NDMP (with two variants - IMAGE - with TOC, single file recovery option and FULL/DIFF approach - OR SnapMirror-to-TAPE - fully block level, FULL only (at the moment))
b) file level (as you would backup a shared disk) - with incremental forever etc.

SnapDiff is used in b) scenario - this function returns changed files between two snapshots - so consider it something like journaling - you do not need to traverse the filesystem to find the changed files - this function gets you the list.

Hope I did not blur it too much :)

Harry
 
PREDATAR Control23

You are correct. The customer is using NetApp as a NAS device in the way you described.

These aren't big shares, and they're not expected to grow very large. The largest share right now is only about 2TB and 1.5 million files. I'm currently backing them up through UNC pathing on 3 different Wintel "management" boxes. The wintel boxes have accounts which run the schedule services which have access into the vfilers. This works great, and I have these 3 different Wintel nodes in a copy group that's shared dynamic. But "fuzzy" copies of open files aren't going to satisy this customer. We've also run into trouble convincing this customer to script the mounting/dismounting of these shares. If we could do that, we could probably turn on client side Open File Support and we'd be fine.

We need file level restorability, so I'm thinking NDMP with TOC is the way to go ... IF that'll give us a non "fuzzy" copy of any file that's currently open at the time of the backup? I'm not 100% sure how that works. I don't think snapmirror to tape will work for this customer because of the file level restorability.

Snapdiff seemed like a good option, but I'm not sure if the share needs to be mounted in order for that to work? And would that be any closer to the native Open File Support that comes with the backup/archive client?

Because the shares are small, I can remove a lot of variables from the equation here ... but the one thing that drives this is getting a clean lock on a file, or at least ensuring that it's not a "fuzzy" copy of the file at the time of the backup.

Thoughts?

Sincere thanks!
C.J.
 
PREDATAR Control23

Hi,

using NDMP (which triggers its own snapshot or uses designated snapshot) or backing up at file level using snapshots - this all is the same from the open file point of view. Files in snapshots are "closed" - therefore backed up - but may be "fuzzy" (the example with long running copy and the snapshot created in the middle).
I do not think "mounting" the filesystem and turning OFS on helps you here - what OFS does? It creates snapshot (using VSS or LVSA) - and this is for block devices only - for CIFS shares the server does not "own" the filesystem.

Summarizing this - in my opinion using NetApp based snapshot is equivalent to OFS - you get all the files closed but possibly inconsistent - but I do not think you can do better that that without integration/application awareness.

Open to discussion :)

Harry
 
PREDATAR Control23

I spoke to a NetApp guy today on this subject. He told me that NDMP backups issue a "Consistancy Point" CP which flushes all writes to disk before the snapshot is taken. In that way, the block level snapshot picks up a consistent backup. He seemed to think this was as close to true "open file support" as we'd get.
 
PREDATAR Control23

Hi,

well ... this is what CP (consistency point) is - just a special kind of snapshot (from TR3002 - http://media.netapp.com/documents/wp_3002.pdf)

... WAFL avoids the need for file system consistency checking after an unclean shutdown by creating a special Snapshot called a consistency point every few seconds ...

but time is not the only cause of CP creation - other are log full, data change high enough and ... snapshot creation
(more can be found here - NOW account required - https://kb.netapp.com/support/index?page=content&id=3012539)

So every snapshot creation gets NetApp WAFL into CP state. NDMP backup creates its own snapshot (or uses designated snapshot - can be set using VIRTUALFSMAPPING) - so using NDMP or any other technique backing up the snapshot is equivalent.

There is one thing we have to keep in mind - there is filesystem consistency (this is what CP does) and application consistency of the file - this cannot be done without application integration no matter what snapshot technology you use (VSS, LVSA, NetApp, ZFS ....).

File locks are not kept in the snapshot (they are related to active filesystem - kept in the memory of NetApp filer) - snapshot is just collection of pointers to the disk blocks - so if you read the snapshot, there is no locked file there - everything can be backed up.

Application consistency of the file cannot be guaranteed - question is if it makes any difference - even if you have your fileserver on the Windows machine (with TSM client on it) and use OFS, you do not get better results.

Long story short - I would not be afraid of any method you choose - just have in mind NDMP has its limitations and is no "silver bullet".

Harry
 
PREDATAR Control23

Thanks, Harry. In my research, I came to the same conclusion. Application consistency cannot be guaranteed. There really is no silver bullet.
 
Top