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.
|
