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:stefan.holzwarth AT ADAC DOT DE]
Sent: 29 July 2003 13:49
To: ADSM-L AT VM.MARIST DOT EDU
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:David.McClelland AT REUTERS DOT COM]
Gesendet: Dienstag, 29. Juli 2003 10:44
An: ADSM-L AT VM.MARIST DOT EDU
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:stefan.holzwarth AT ADAC DOT DE]
Sent: 29 July 2003 07:06
To: ADSM-L AT VM.MARIST DOT EDU
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:gordon.woodward AT DB DOT COM]
Gesendet: Dienstag, 29. Juli 2003 04:01
An: ADSM-L AT VM.MARIST DOT EDU
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.
|
