-----Original Message-----
From: Bell, Charles (Chip)
Sent: Wednesday, April 29, 2009 4:36 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: RE: [ADSM-L]
Well, you're close. There are 36 NTFS mount points presented, and the app
only fills each up one at a time, sequentially. It is on 21 of 36 right now,
I believe.
I agree with your assessment on the monthly backups, but I will probably
stick with it for the comfort of the app owner, especially since she is being
this flexible.
Thanks a lot for the input!!! :)
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Dwight Cook
Sent: Wednesday, April 29, 2009 4:28 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L]
IMAGE backup is the way to go.
You are backing up from the server that owns the storage and presents the
NTFS, correct?
And that has 36 different areas that are presented as NTFS to this other
server but that other server only needs one per day??? Or 20 are presented,
19 are full, and the application will write to the 20th until it is full,
then it will add another NTFS (the 21st... the first 20 will now basically
be full/readonly and the 21st will be read/write)...???
You'll have to have a static period to capture your image backup...
If the data is really static, I'd run one backup, have a copy storage pool
and then not even worry with monthly backups of the same old stuff... but
depending on the size of your tape media and reclamation activity, a monthly
refresh of the data could be a good deal to ensure its usability.
Nightly image of the active system... yea... and since the old won't go
inactive until the following is successful and it won't expire the old data
out until the new data is copied successfully and expiration runs, you could
be safe / guaranteed of having good data on TSM at all times.
You might not want to run expiration until after you successfully run your
backup stgpool command in case your tape drive eats your primary tape during
copy... and in any event, if that were to happen you would want to
investigate what data was on it and rerun a backup to capture that data
again.
But yes
Versions data exists: 1
Versions data deleted: 0
Retain Extra: 0 days
Retain Only: 0 days
Would result in at most a brief period when 2 copies would exist but
generally only 1
Situation....
Monday, backup, you have an active copy
Tuesday, backup, you have a new active copy and one marked inactive /
flagged for deletion due to Versions Data Exists
Tuesday if Expiration runs after the Tuesday backup successfully
finishes, then that inactive copy would in fact be purged from the system.
Now with image backups, the last one will never expire naturally...
You can look for the thread "Once again I've a problem on the TSM client
side with specifying a path for an object" from Tom Kauffman of NIBCO where
he was trying to purge an old image backup from his TSM server.
Dwight
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bell, Charles (Chip)
Sent: Wednesday, April 29, 2009 3:51 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L]
Well, I'm showing my current config, and further down, I'm asking what would
be the best way to do it? One of the problems is that there are 36 NTFS
mount
points presented through this one server (called EHIMFS1), and each mount
point has 5 to million files each. I had to attempt to back all of that up
within one business day, until their app came up with a way to only use one
mount point at a time. Their app is designed in a way that the user cannot
alter the original file, but can create modifications that serves as
pointers
to the original file. The app owner is usually very careful about this sort
of thing, but she seems to have no reservation going to the "Let's keep only
the active copy, if the files are never changing". It's driving my TSM DB
size way up, and it almost fully utilized. I don't want to add more to the
220+ GB it already is.
The scenario
The first 19 mount points are "full" to their app. I have been told I can
back these up once a month, and I want to change from incremental to image
backup, change the retention to keep one copy of any kind (hence the
active),
so that the previous incremental backups will expire and I can reclaim DB
space backup... WHEW!
I would backup the most recently "filled" mount point, the one currently
being written to, and the next-to-be-written-to on an incremental basis, and
so on. As one has been filled, it will move to a monthly image backup. Am I
not making sense in my thinking?? Please straighten me out if not...
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Dwight Cook
Sent: Wednesday, April 29, 2009 3:40 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L]
Can I add a comment...
What if you have some form of file system corruption from anything and the
file appears to have changed, TSM backs up the corrupt version and purges
off the old copy???
If the files are as you say and never change, you won't have any inactive
versions as long as active versions exist and if a file is accidentally
deleted you would want some time to recover...
In looking at your current settings, from a business point of view, they are
very sound and (if the files are as you say) you will only have one copy of
the data, until something is deleted and then you will have 60 days to
figure out someone incorrectly deleted a file and recover it.
Again, if those files never change, your existing config will only have a
single copy of the data... the current/active version.
Dwight
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Bell, Charles (Chip)
Sent: Wednesday, April 29, 2009 2:55 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L]
I have a copygroup set up for a domain that is strictly a bunch of nodes for
a document imaging application, millions of files each. I am going to change
the backups from the incremental-forever to image backups. Also, I am going
to change the retention to where I would only keep the active copy of each,
and that's it. I don't want any inactive copies, and I don't want to keep
them around for ANY amount of time, only the active. Reason being, the files
in those NTFS file systems never change, and they are only archives.
Here is the current config
Versions Data Exists 2
Versions Data Deleted 1
Retain Extra Versions 30
Retain Only Version 60
Based on my comments above, would that need to be?:
Versions Data Exists 1
Versions Data Deleted 0
Retain Extra Versions 0
Retain Only Version 0
Please help...This is one of the parts I hate about TSM. I know it's
probably
simple, but I never can seem to remember what each retention parameter (as
shown above) MEANS! J
God bless you!!!
Chip Bell
Network Engineer I
IBM Tivoli Certified Deployment Professional (ITSM)
Baptist Health System
Birmingham, AL
|
