Stefan Fair enough, and if you've made proven progress in your company of using the openfile snapshot feature (which I personally have not yet played with) then good stuff!
My only experience (using the below configuration) was in an AIX Notes server environment which was a) pretty large and b) pretty active. In the amount of time taken for the ba client to have piped a 100MB or larger (sometimes well into GB for some users) .nsf mailfile or database to its TSM server it would the majority of the time have gotten written to and caused an inconsistency, which for a user's mailfile backup just wasn't worth the risk. Nor could we afford downtime on the live service. Admittedly, it certainly wasn't a cheap solution, requiring lots of extra hardware and support, but our guys looked into using TDP for Domino and it just wasn't even slightly feasible in the size of our environment at the time (using 3494/3590 and local SSA disk as we were), with projections for simple restores taking *so* many tape mounts and *so* much time. So, in summary - whatever works for your scale of environment is good, but just ensure that *plenty* of testing is carried out and carries on being carried out to ensure that your restores are good ones. After all how many times have we said to our customers, "Oh yes, the backups are running fine!" and then muttered under our breath, "it's the restores that are going to be the problem..." ;o) All the best, David (now using Outlook instead of Notes!) McClelland Global Management Systems Reuters Ltd -----Original Message----- From: Stefan Holzwarth [mailto:[EMAIL PROTECTED] Sent: 29 July 2003 13:49 To: [EMAIL PROTECTED] Subject: AW: Lotus Notes Non-TDP backups Hi David, as i understood the openfile feature a snapshot is made for the whole filesystem. Therefore there should be no problem with db-consistency between db-files if they live all on the same volume. Since in my company our lotus db files have proofen some kind of robustness (we only have a small domino environment) i can not total agree with your absolute no to this topic. Domino uses an underlaying simple database that has to maintain some robustnes towards sudden failures like power off, lost connectivity to the db on a networkshare or some bluescreens. From the other side if an openfile agent waits (configurable) for seconds for inactivity there should not occur a cut through a write operation. I'm sure there are better and more saver ways doing backups of Domino, but most need more efforts or resources. Kind regards, Stefan Holzwarth -----Ursprüngliche Nachricht----- Von: David McClelland [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 10:44 An: [EMAIL PROTECTED] Betreff: Re: Lotus Notes Non-TDP backups Stefan, Gordon, Urrgh - no! As soon as you try to restore any of these files which will have changed during the backup, even with open file support, you'll more than likely get a corrupt .nsf database! Notes .nsf files are pretty sensitive and any change somewhere in one part of the db will have repercussions elsewhere in the db and before you know it you won't be able to open up the .nsf at all, and will get 'b-tree structure invalid' or similar complaints from Notes. You need to have the Notes server process 'down' in order to quiece the databases and prevent them from being written to before backing them up. The *usual* way of handling Notes backups without using TDP is to use a 'backup' server - the concept works like this: You have a separate Notes server (i.e. a 'backup Notes server) which contains replicas of the databases on the live Notes servers. Using Notes replication, all changes to the live databases are replicated to the replicas on the backup server. At a time controlled by you, you take the Notes server process down on the backup server (as no users connect directly to the backup Notes server, there will be no outage) and then perform the backups of the now quiesced .nsf files using the normal TSM BA client. Once the backup is complete, bring up the Notes server on the backup server and begin replication with the live servers to the backup .nsf's up to date again. Depending upon hardware, you can have many live Notes server's worth of .nsf's contained on a single backup Notes server - just ensure you have enough time to replicate the data from live to backup server. In terms of recoveries, as the backup Notes server is down during backups, you might want to have an additional Notes partition somewhere on a backup server which you can use as a 'recovery server' - a Notes server which is *always* up, regardless of whether a backup is taking place. Users can connect to this directly and pull back any recovered .nsf databases, or even just documents from a .nsf. Hope this helps :o) David McClelland Global Management Systems Reuters Ltd -----Original Message----- From: Stefan Holzwarth [mailto:[EMAIL PROTECTED] Sent: 29 July 2003 07:06 To: [EMAIL PROTECTED] Subject: AW: Lotus Notes Non-TDP backups I would try openfile support in 5.2 . First tests look quite good. Regards Stefan Holzwarth -----Ursprüngliche Nachricht----- Von: Gordon Woodward [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 29. Juli 2003 04:01 An: [EMAIL PROTECTED] Betreff: Lotus Notes Non-TDP backups We currently have over 160Gb of Notes mail databases that need to be backed up nightly. Due to incompatabilities with the Notes TDP, our version of TSM (v4.2.2.5) and the way compaction runs on our Notes servers, we have to use the normal Tivoli backup client to backup the mailboxes. It takes about 12 hours for all the databases to get backed up each night but the vast amount of this time seems to be spend trying and then retrying to send mailboxes to the TSM server. A typical schedule log looks like this: 28-07-2003 19:51:53 Retry # 2 Normal File--> 157,548,544 \\sdbo5211\d$\notes\data\mail\beggsa.nsf [Sent] 28-07-2003 19:52:28 Normal File--> 70,778,880 \\sdbo5211\d$\notes\data\mail\bingleyj.nsf [Sent] 28-07-2003 19:54:05 Retry # 1 Normal File--> 349,437,952 \\sdbo5211\d$\notes\data\mail\bignasck.nsf [Sent] 28-07-2003 19:55:10 Normal File--> 131,072,000 \\sdbo5211\d$\notes\data\mail\Bishnic.nsf Changed 28-07-2003 19:56:58 Normal File--> 265,289,728 \\sdbo5211\d$\notes\data\mail\bellm.nsf [Sent] 28-07-2003 19:58:08 Retry # 1 Normal File--> 131,072,000 \\sdbo5211\d$\notes\data\mail\Bishnic.nsf [Sent] 28-07-2003 20:00:46 Normal File--> 387,186,688 \\sdbo5211\d$\notes\data\mail\BLACKAD.NSF Changed 28-07-2003 20:03:52 Normal File--> 367,263,744 \\sdbo5211\d$\notes\data\mail\BERNECKC.NSF Changed 28-07-2003 20:06:18 Retry # 1 Normal File--> 387,186,688 \\sdbo5211\d$\notes\data\mail\BLACKAD.NSF [Sent] 28-07-2003 20:10:11 Normal File--> 1,011,613,696 \\sdbo5211\d$\notes\data\mail\binneyk.nsf Changed 28-07-2003 20:11:52 Retry # 2 Normal File--> 953,942,016 \\sdbo5211\d$\notes\data\mail\andrewsj.nsf [Sent] 28-07-2003 20:12:01 Retry # 1 Normal File--> 367,263,744 \\sdbo5211\d$\notes\data\mail\BERNECKC.NSF [Sent] 28-07-2003 20:12:05 Normal File--> 10,485,760 \\sdbo5211\d$\notes\data\mail\bousran.nsf [Sent] 28-07-2003 20:13:40 Normal File--> 720,633,856 \\sdbo5211\d$\notes\data\mail\BLACKC.NSF Changed 28-07-2003 20:18:58 Retry # 3 Normal File--> 1,863,057,408 \\sdbo5211\d$\notes\data\dbecna.nsf Changed Is there anything we can do reduce the window for this backup? Both the TSM server and our Notes server have dedicated 1Gb links so bandwidth isn't a problem. The Backup Copy Group for the Management Class the Notes data is allocated to has Copy Serialization set to 'Shared Static'. Would changing this to Dynamic be beneficial in reducing the amount of retries that occur and also setting CHANGERETRIES to a lower option help? Thanks in advance, Gordon Woodward Senior Support Analyst Deutsche Asset Management (Australia) Limited -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. --------------------------------------------------------------- - Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. --------------------------------------------------------------- - Visit our Internet site at http://www.reuters.com Get closer to the financial markets with Reuters Messaging - for more information and to register, visit http://www.reuters.com/messaging Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
