Hi Richard,

first, thank you for your reply. You'are absolutly right with the mirrored 
filesystem or maybe a clustered system. In fact I'm not sure if it's mirrored 
or if it is a Raid 5 system (because I'm not the admin of this system - I have 
to ask my colleague). I'm only responsible for backing up this system to TSM 
and I want search a good way how to resolv this. The backups are for complete 
disaster recovery purposes (but we should also be able to recover a single file 
from tsm)

About the Filesystems:
>From time to time I look at this system and edit the inclexcl.lst and exclude 
>the filesystems which are mounted to the state readonly. But there are a lot 
>of new filesystems for every mandator (client) (I don't if this the correct 
>english word). Every Filesystem for every mandator have at least one ReadWrite 
>Filesystem. And there are many many mandators. This is the reason for the long 
>running examination.

I think of only making IMAGE backups of the filesystems which are in readonly 
state (to reduce the TSM Database). And in the situation of recovering a single 
file we we have to recover the 40 GB to a temp Filesystem and the copy the 
required file to the orginal place). Is journaling a good alternative for the 
ReadWrite Filesystems? I don't have any experience with Journaling. And I don't 
know at which time a filesystem is remount to readonly and a new one is created.
Or should we better archive all the images?

I don't know which is the optimal way in our situation in regard of backing up 
(or archive) the system to our TSM environment.


With kind regards,
Boris
 

-----Ursprüngliche Nachricht-----
Von: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Im Auftrag 
von Richard Sims
Gesendet: Dienstag, 3. Juli 2007 15:55
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Re: [ADSM-L] Backup/Archive our Document Management System


Boris -

If the data is as important as "disaster for our company" suggests, then the 
file systems should be mirrored, rather than the apparent current configuration 
where there is a single disk copy in existence with attendant calamity when the 
disk develops problems.  Computer center administrators can then swap in new 
disks as the old ones age and one side of the mirror fails.

>> Our backup runs today over 40 hours...

Why?  If all new documents are going to a newly created file system in a 
series, and all past file systems in the series are dormant read- only, then 
there should be a maximum of 1 million files being examined in daily backups, 
which is manageable.  That is, all the old file systems are no longer 
updateable and have complete, static backups and need not be examined any 
further.

If the old file systems are seldom referenced, you might want to consider 
performing a TSM Archive on their contents, making a safety copy of the data in 
TSM storage (and an offsite copy), then retire the old disk (and maybe the 
backups) and have sporadic references to the old data be served by TSM Retrieve.

Growth of the TSM database will be the big headache with this; but this is 
something that large sites have to contend with, typically by expanding to a 
second server once the db size, its backup, and expirations all become too much.

   Richard Sims