[ADSM-L] AW: [ADSM-L] Backup/Archive our Document Management System
2007-07-04 05:01:14
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
|
|
|