And to the list as well
________________________________
From: Lerch, Alfred Sent: Donnerstag, 21. Juni 2007 22:48 To: 'Page, Jeremy'; 'owner-toasters@mathworks.com' Subject: RE: NDMP tuning on a 270c
Hi Jeremy,
see NetApp Bug 96894: Phase I of NDMP based backups is slow fixed in 7.0.6 - so this could well be the issue you encounter
regards
alfred
Bug Detail
Bug ID 96894 Title Phase I of NDMP based backups is slow. Duplicate of Bug Severity http://now.netapp.com/NOW/knowledge/docs/defs/boldefs.shtml#severity 3 - Serious inconvenience Bug Status http://now.netapp.com/NOW/knowledge/docs/defs/boldefs.shtml#status Fixed Product http://now.netapp.com/NOW/knowledge/docs/defs/boldefs.shtml#product Data ONTAP Bug Type http://now.netapp.com/NOW/knowledge/docs/defs/boldefs.shtml#type Backup/Restore Description Formatted http://now.netapp.com/NOW/cgi-bin/bol?Type=Plain&Display=96894 For NDMP backups with File History enabled, Phase I is slow. The extent of slowness may depend on fragmentation of the inode file and the file system. With Data Ontap 6.4 onwards, NDMP backups with File History add some processing in Phase I. This processing is required for DAR Enhancements (A restore time feature), which are a part of Data Ontap 6.4 or beyond. The slowness is attributable to performance bottlenecks in this additional processing. Workaround Formatted http://now.netapp.com/NOW/cgi-bin/bol?Type=Plain&Display=96894 Backups without file history continue to perform as expected. For backups where performance of Phase I is bothersome, file history can be turned off temporarily until a fix is available. For a workaround to turn off the additional processing during Phase I (Offset map generation), without disabling the file history, please track bug 102211. Notes Formatted http://now.netapp.com/NOW/cgi-bin/bol?Type=Plain&Display=96894 Related Solutions
Fixed-In Version * Data ONTAP 6.4.2P4 http://now.netapp.com/download/software/ontap/6.4.2P4/ (First Fixed) - Fixed * Data ONTAP 6.4.5 http://now.netapp.com/download/software/ontap/6.4.5/ (GA http://now.netapp.com/download/defs/ontap.shtml ) - Fixed * Data ONTAP 6.5.7 http://now.netapp.com/download/software/ontap/6.5.7/ (GA http://now.netapp.com/download/defs/ontap.shtml ) - Fixed * Data ONTAP 7.0.6 http://now.netapp.com/download/software/ontap/7.0.6/ (GD http://now.netapp.com/download/defs/ontap.shtml ) - Fixed * Data ONTAP 7.1.2.1 http://now.netapp.com/download/software/ontap/7.1.2.1/ (GA http://now.netapp.com/download/defs/ontap.shtml ) - Fixed * Data ONTAP 7.2.2 http://now.netapp.com/download/software/ontap/7.2.2/ (GD http://now.netapp.com/download/defs/ontap.shtml ) - Fixed
________________________________
From: Page, Jeremy [mailto:jeremy.page@gilbarco.com] Sent: Donnerstag, 21. Juni 2007 14:02 To: Lerch, Alfred Subject: RE: NDMP tuning on a 270c
7.05. I was just in Munich Monday, had a great time.
Jeremy M. Page, MCSE, CNA, CCNA _____
* email:Jeremy.Page@gilbarco.com - ( phone: 336.547.5399 - 6 fax: 336.547.5163 - ( cell: 336.601.7274
________________________________
From: Lerch, Alfred [mailto:alfred_lerch@mentor.com] Sent: Thursday, June 21, 2007 3:26 AM To: Page, Jeremy Subject: RE: NDMP tuning on a 270c
Hi Jeremy,
which ONTAP version are you using? We had such an issue two years ago and it was a bug in ONTAP. (Unfortunately now.netapp.com is out of order right now so I cannot look it up.)
regards
alfred
+====================================================================+ |Alfred Lerch Mentor Graphics Deutschland GmbH| |Network & System Administrator Arnulfstrasse 201| |IT ESC Europe D-80634 Muenchen, Germany| |email: alfred_lerch@mentor.com Geschäftsführer: Dean Freed| |Tel. : +49 89 57096-241 Registergericht München HRB 106955| |Mobile: +49 172 8915200 Fax : +49 89 57096-400| +====================================================================+
________________________________
From: owner-toasters@mathworks.com [mailto:owner-toasters@mathworks.com] On Behalf Of Page, Jeremy Sent: Mittwoch, 20. Juni 2007 14:26 Cc: toasters@mathworks.com Subject: RE: NDMP tuning on a 270c
I guess my gripe is why does Netbackup lock a drive when it's doing the scan. I understand it can't do the backup until it knows *what* it's going to backup, the confusion on my part is why that would lock a tape.
Also, for some reason (I'm not the backup guy so I am probably missing something) we need all our tapes to do a single file restore anyways, seems like you are saying that's not normal.
Jeremy M. Page, MCSE, CNA, CCNA _____
* email:Jeremy.Page@gilbarco.com - ( phone: 336.547.5399 - 6 fax: 336.547.5163 - ( cell: 336.601.7274
________________________________
From: tmac [mailto:tmacmd@gmail.com] Sent: Tuesday, June 19, 2007 2:47 PM To: Page, Jeremy Cc: toasters@mathworks.com Subject: Re: NDMP tuning on a 270c
The Miserable File History problem....
I actually have a level 0 that takes over 8 hours to pass file history info which means the dump does not start until that point.
Just for kicks, you could modify your policy to have the first line as "set hist = n" (without quotes). This will kill the file history. You will be unable to restore files (directories only) and you will not have DAR which means you will have to read the ENTIRE backup tape or tape set. Instead of looking at pure size, do a "df -h" and a "df -i" to how much and how many (files) you are backing up. You can always dived the size used by the files used to see average file size.
Heck for that matter you could scan the filesystem with the filestats command and you could scan from a NFS client to see which directories are huge (I have a number of directories that are 50MB in size-> this KILLLLS a backup)
On 6/19/07, Page, Jeremy jeremy.page@gilbarco.com wrote:
We are backing up a 270c nightly with Netbackup via NDMP to a dual drive LTO3 machine (only one drive is used for to backup the filer). There are 2.25 TB on one head and 1.1TB on the other. For a full backup it takes about 10 hours to write to tape, which I don't think is too bad (larger volumes hit 31200 KB/sec reported by Netbackup), but the differentials take 5 hours to run,even though the delta on our data is very small. I suspect this is more of a Netbackup issue then a filer based one but wanted to throw it out there incase there was something I should look at on the host side. This is over a normal gigE switched network connection with the default settings on the filer, network-wise. We are not using virtual interfaces, both heads have a single 1 gig connection to the LAN. Any suggestions or inventive flames are welcome.
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.