Hi Gurus,
we backup our oracle database using rman to TAPE by TSM media management.
Currently Backup Retention policy has been set to 30 days. Please guide me on
how to configure Back up Retention period to 60 days?
-Sujatha
, 2010 12:43 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Data retention period 60days
Hi Gurus,
we backup our oracle database using rman to TAPE by TSM media management.
Currently Backup Retention policy has been set to 30 days. Please guide me on
how to configure Back up Retention period to 60
thank you. what changes we need to make in rman
+--
|This was sent by sujatha@gmail.com via Backup Central.
|Forward SPAM to ab...@backupcentral.com.
+--
Of
Kelly Lipp
Sent: Thursday, January 21, 2010 1:31 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Data retention period 60days
Figure out which management class is governing your Oracle backups. Q
node nodename where nodename is the name the client uses to identify
itself. Check to see which policy domain
:31 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Data retention period 60days
Figure out which management class is governing your Oracle backups. Q
node nodename where nodename is the name the client uses to identify
itself. Check to see which policy domain the node is in.
Q copy domainname f=d
.
From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Sujatha chk
[tsm-fo...@backupcentral.com]
Sent: Thursday, January 21, 2010 10:42 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Data retention period 60days
Hi Gurus,
we backup our oracle database using rman to TAPE by TSM
From: Bell, Charles (Chip)
Sent: Wednesday, April 29, 2009 2:55 PM
To: 'ADSM-L@VM.MARIST.EDU'
Subject:
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
-Original Message-
From: Bell, Charles (Chip)
Sent: Wednesday, April 29, 2009 3:51 PM
To: 'ADSM: Dist Stor Manager'
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
-Original Message-
From: Bell, Charles (Chip)
Sent: Wednesday, April 29, 2009 4:36 PM
To: ADSM-L@VM.MARIST.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
Boy, it sure looks like you'll have three versions forever on this one.
Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777 x7105
www.storserver.com
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Nick
Wanted to get some thoughts on what people are doing for
Long Term Data Retention - specifically on obsolete applications.
Say we have an NT 4.0 system that is no longer used. Business
owner says we need to keep for 25 years. I know not
practical/possible for a number of reasons. Even if we
required that some data be deleted when there was no longer an
operational need for it.
After convincing them that TSM was not an appropriate vehicle, using a
reducio ad absurdum argument, I researched a little further.
The best method for long term data retention is probably flat XML files
I am using an Oracle TDP. I have 6TB of old Oracle data on both the onsite
and offsite tapecopy pools. I need to delete the vast majority of data in
both pools. As the data is spread over several tapes is there any way of
deleting the data from the node side? Or do I need to set up a new policy
to
On May 3, 2008, at 12:30 PM, David Hensley wrote:
I am using an Oracle TDP. I have 6TB of old Oracle data on both the
onsite
and offsite tapecopy pools. I need to delete the vast majority of
data in
both pools. As the data is spread over several tapes is there any
way of
deleting the data from
Hello Everyone,
We have been notified that we need to keep data that had been backed up
under our Lotus Notes server from the past 2 weekends. They are on AIX
servers with OS level 5.2 and TSM TDP Domino Client 5.2.2.0. Following is
the currently used management class:
Mgmt Class Name
MC2V30D
Joni,
I can't quite tell what your ultimate goal is here.
You don't tell us how often you run a backup and/or if you
are using Domino transaction logging or not. You also
don't mention if this is a new requirement, or just a
one time thing needed for a particular purpose.
As a general rule of
Many thanks for the excellent responses to my question
Computers are great but organics are better.
John
/p
**
/p
The information in this E-Mail is confidential and may be legally privileged.
It may not represent the views of
Hi out there,
Just wondering what the consensus is on the best way to retain TSM client
data that has to be kept for many years (legal requirement) after the
client box is retired.
I have consideredf various approaches
1) Export
2) Backup set
3) Create a new domain for retired clients which have
I'd be interested in the same info as regards NetApp client data, ie:
NDMP dump backups.
Iain
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
John Naylor
Sent: 14 July 2005 10:28
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Long term data retention
@vm.marist.edu
cc
Subject
Long term data retention for retired clients
Hi out there,
Just wondering what the consensus is on the best way to retain TSM client
data that has to be kept for many years (legal requirement) after the
client box is retired.
I have consideredf various approaches
1) Export
2
On Jul 14, 2005, at 5:27 AM, John Naylor wrote:
I have considered various approaches
1) Export
2) Backup set
3) Create a new domain for retired clients which have the long term
retention requirement
Hi, John -
Another possibility for your list is TSM for Data Retention.
This would be more
:
Sent by: ADSM: Dist Stor Subject: Long term
data retention for retired clients
Manager
ADSM-L@VM.MARIST.EDU
07/14/2005 05:27 AM
Please respond to ADSM:
Dist Stor Manager
On Jul 14, 2005, at 8:45 AM, Richard Rhodes wrote:
If there was one thing I really wish in all this was a comments
field. The
only place we found to put comments about a node is in the contacts
field.
I wish there was another field where we could enter comments.
...
Richard -
With a
If there was one thing I really wish in all this was a comments field. The
only place we found to put comments about a node is in the contacts field.
I wish there was another field where we could enter comments.
The 'define machine' and 'insert machine' commands can be used to store
large
Remember - moving the nodes to a new domain does nothing to rebind the data
to new management classes - that only happens during an actual backup. So
the data will stick around for as long as intended, except for the last
active version of the files. Those you have to delete manually. One
== On Thu, 14 Jul 2005 10:27:49 +0100, John Naylor [EMAIL PROTECTED] said:
I have consideredf various approaches
1) Export
2) Backup set
3) Create a new domain for retired clients which have the long term
retention requirement
I see export and backup sets as reducing database overhead, but
== On Thu, 14 Jul 2005 08:45:11 -0400, Richard Rhodes [EMAIL PROTECTED] said:
If there was one thing I really wish in all this was a comments field. The
only place we found to put comments about a node is in the contacts field.
I wish there was another field where we could enter comments.
PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Long term data retention for retired clients
== On Thu, 14 Jul 2005 10:27:49 +0100, John Naylor
[EMAIL PROTECTED] said:
I have consideredf various approaches
1) Export
2) Backup set
3) Create a new domain for retired clients which have the long term
Hello,
we will test and use TSM for Data Retention in our Doumentum application.
Objective being to be sure archives will be retained UNCHANGED for the
specified retention period (version safe). Min level: TSM 5.2.2
Anybody already tested this new function of TSM server or TSM clients ?
Would
Hi All,
I've just come back from two weeks working on something else and caught up with the
list, and I can't help jumping in with this one even if it's late.
How about
backup TSM DB and shutdown current TSM instance (henceforth this is TSM-A)
create second TSM instance on same physical
Yes, Step 4 is to CYA. Tape isn't 100% foolproof for data retention, and
the closer you get to Forever, the less stable it will be, so having two
copies would help ensure you have the data should a request be made for it
in the future.
Let's use an imaginary media called Tangwort. If you say
to ADSM: Dist Stor Manager [EMAIL PROTECTED]
Sent by:ADSM: Dist Stor Manager [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject:Re: Eternal Data retention brainstorming.
What kind of shelf life are you expecting for your media? Since they've
discovered that optical has
, Wanda [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 16, 2002 10:58 AM
To: [EMAIL PROTECTED]
Subject: Re: Eternal Data retention brainstorming.
That will work for the active data in the old (renamed) filespaces, but I
believe the inactive data in the renamed filespaces will continue to expire
]
Subject: Re: Eternal Data retention brainstorming.
Dang, my mails are long-winded. Forgive me if I'm boring those of
you who are not interested. Fell free to use the delete button. :-)
There's been a lot of good suggestions sent to me. The real kicker
is that with the volume
Have you considdered using archiving to store the data that needs to be
kept forever? I've very sure no government org is really intrested in
your /etc/passwd file for over 1o years back. Find out what you need to
keep and set up archiving
On donderdag, augustus 15, 2002, at 09:30 , bbullock
that is only $183,333.00
CHEAP ! ! !
(oh, that's my supplier's price on K tapes, if that is good or bad ???)
Dwight
-
-Original Message-
From: bbullock [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 15, 2002 2:31 PM
To: [EMAIL PROTECTED]
Subject: Eternal Data retention brainstorming
:
Sent by: Subject:
ADSM: Dist Re: Eternal Data retention brainstorming.
Stor Manager
[EMAIL PROTECTED]
IST.EDU
08/16/02 07:09
AM
Please
copypool tapes into the
library during the restore.
That's my theory at this point.
Ben
-Original Message-
From: Ramnarayan, Sean A [EDS] [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 16, 2002 4:09 AM
To: [EMAIL PROTECTED]
Subject: Re: Eternal Data retention brainstorming.
Hi
I
Wanda... or anyone... one question. When changing retention settings for a
management class, are they immediately processed by TSM or does the next
backup have to run to rebind all the files to the new class settings ?
If it is the latter, the files that no longer exist on the client, but are
What kind of shelf life are you expecting for your media? Since they've
discovered that optical has data decay, it's not even forever! I've seen
some others on the list point at it, but how will you restore this data in
10 years?
Here's what I'd look at doing:
1. Take about 5 dbbackups (or
:[EMAIL PROTECTED]]
Sent: Friday, August 16, 2002 9:09 AM
To: [EMAIL PROTECTED]
Subject: Re: Eternal Data retention brainstorming.
How about a backupset of every node on that day? Of course, it would have
to be today I guess...
Robin Sharpe
Berlex Labs
Cook, Dwight
-
From: Slag, Jerry B. [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 15, 2002 4:30 PM
To: [EMAIL PROTECTED]
Subject: Re: Eternal Data retention brainstorming.
If they tell you the hosts/filespaces just do a rename of the existing
filespaces.
-Original Message-
From: bbullock
of the request and the volume
of data involved.
Thanks,
Ben
-Original Message-
From: Nicholas Cassimatis [mailto:[EMAIL PROTECTED]]
Sent: Friday, August 16, 2002 8:46 AM
To: [EMAIL PROTECTED]
Subject: Re: Eternal Data retention brainstorming.
What kind of shelf life are you expecting for your
Folks,
I have a theoretical question about retaining TSM data in an unusual
way. Let me explain.
Lets say legal comes to you and says that we need to keep all TSM
data backed up to a certain date, because of some legal investigation
(NAFTA, FBI, NSA, MIB, insert your
: Thursday, August 15, 2002 3:31 PM
To: [EMAIL PROTECTED]
Subject: Eternal Data retention brainstorming.
Folks,
I have a theoretical question about retaining TSM data in an unusual
way. Let me explain.
Lets say legal comes to you and says that we need to keep all TSM
data
how about renaming the filespace, This will keep your active versions.
-Original Message-
From: bbullock [SMTP:[EMAIL PROTECTED]]
Sent: Thursday, August 15, 2002 12:31 PM
To: [EMAIL PROTECTED]
Subject:Eternal Data retention brainstorming.
Folks,
I
]
Subject: Eternal Data retention brainstorming.
Folks,
I have a theoretical question about retaining TSM data in an unusual
way. Let me explain.
Lets say legal comes to you and says that we need to keep all TSM
data backed up to a certain date, because of some legal
of tapes will take some timemaybe more than
24hrs / day?
Maybe use the exercise as an excuse to change tape technology!
-Original Message-
From: bbullock [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 15, 2002 3:31 PM
To: [EMAIL PROTECTED]
Subject: Eternal Data retention brainstorming
If they tell you the hosts/filespaces just do a rename of the existing
filespaces.
-Original Message-
From: bbullock [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 15, 2002 2:31 PM
To: [EMAIL PROTECTED]
Subject: Eternal Data retention brainstorming.
Folks,
I have
As a refinement to Wanda's final suggestion, couldn't you alter
your policies for 'del volhist type=dbb' (or simply retain the
current copy of your database backup exclusive of the volume
history), and then modify your storage pool's reusedelay
parameter appropriately?
The drawback that I see is
Message-
From: Prather, Wanda [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 15, 2002 2:09 PM
To: [EMAIL PROTECTED]
Subject: Re: Eternal Data retention brainstorming.
Well, this is an interesting what-if scenario for discussion!
I'll take a crack at it...
1) Painful, but may be the best
with the same
retention settings, right ?
Duane Ochs
Systems Administration
Quad/Graphics Inc.
414.566.2375
-Original Message-
From: Prather, Wanda [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 15, 2002 3:09 PM
To: [EMAIL PROTECTED]
Subject: Re: Eternal Data retention brainstorming
Ben,
I've had to do permanent retention only twice so far.
The first time we did the keep forever change to the management class
associated with our Lotus Notes files. As predicted, data and tape usage
grew unbounded. That helped us decide to migrate from 3570 technology to
LTO.
After that
On Fri, 15 Mar 2002 16:11:12 -0500, Ward, Stuart [EMAIL PROTECTED]
wrote:
In the very near future I will need to put together a software and hardware
proposal for data retention of approximately 50 years due to FDA
regulations encompassing the medical industry.
My main question would
*SMers..
In the very near future I will need to put together a software and hardware
proposal for data retention of approximately 50 years due to FDA
regulations encompassing the medical industry.
My main question would be the type of media to use currently that has any
kind of magneto
will need to put together a software and hardware
proposal for data retention of approximately 50 years due to FDA
regulations encompassing the medical industry.
My main question would be the type of media to use currently that has any
kind of magneto retention life-span nearing or surpassing
Hot Diggety! Ward, Stuart was rumored to have written:
In the very near future I will need to put together a software and hardware
proposal for data retention of approximately 50 years due to FDA
regulations encompassing the medical industry.
Look at NASA. I've talked with various
length to
force the data to be rebuilt onsite before it comes back.
-Original Message-
From: Ward, Stuart [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 15, 2002 4:11 PM
To: [EMAIL PROTECTED]
Subject: Data Retention
*SMers..
In the very near future I will need to put together a software
To: [EMAIL PROTECTED]
Subject: Data Retention
*SMers..
In the very near future I will need to put together a software and hardware
proposal for data retention of approximately 50 years due to FDA
regulations encompassing the medical industry.
My main question would be the type of media to use
- ADSM/TSM
Cell (415) 215-0326
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]] On Behalf Of
Ward, Stuart
Sent: Friday, March 15, 2002 1:11 PM
To: [EMAIL PROTECTED]
Subject: Data Retention
*SMers..
In the very near future I will need to put together a software
]
To: ADSM: Dist Stor Manager [EMAIL PROTECTED]
cc:
Subject:RE: Data Retention
TSM v4.1 for AIX, Administrator's Guide, Table 27 (Table 22 in Windows
guide, Table 26 for Solaris)
NOLIMIT/NOLIMIT60 days/180 days
Retain Extra Versions controls expiration of the versions
Gerald Wichmann [EMAIL PROTECTED] schrieb:
So there is no reason to ever set retain only to less then retain extra
right?
hmm - perhaps to prevent this MC to apply to directory backups (when
DIRMC is not specified) ???
--
Reinhard MerschWestfaelische
With the following retention values:
Versions data exists - nolimit
Versions data deleted - nolimit
Retain extra versions - 14
Retain only versions - 21
When a version is deleted from the server and after 14 days have passed,
is the only version retained for 7 more days or for 21 more days?
On Tue, 13 Nov 2001 10:14:31 -0800, it was written:
Versions data exists - nolimit
Versions data deleted - nolimit
Retain extra versions - 14
Retain only versions - 21
When a version is deleted from the server and after 14 days have passed,
is the only version retained for 7 more days or for 21
718 4238
Gerald
Wichmann To: [EMAIL PROTECTED]
gwichmann@SAcc:
NSIA.COMSubject: Data Retention
Sent by:
ADSM: Dist
Based on how the original question was worded, both Mark's and Bill's
answers below are incorrect.
The last version expires 21 days after it went _inactive_, not after
it became the the only version. In the original question, 14 days
have passed since the file was deleted (and went inactive),
13, 2001 12:43 PM
To: [EMAIL PROTECTED]
Subject: Re: Data Retention
Agreed! Helps to read the question thoroughly.
_
William Mansfield
Senior Consultant
Solution Technology, Inc
David Bronder
david-bronder
:
Sent by: ADSM:Subject: Re: Re: Data Retention
Dist Stor
Manager
[EMAIL PROTECTED]
ST.EDU
11/13/2001
02:18 PM
Please respond
]
To: [EMAIL PROTECTED]
cc:
Subject:Re: Data Retention
So there is no reason to ever set retain only to less then retain extra
right?
Gerald Wichmann
System Engineer
StorageLink
408-844-8893 (v)
408-844-9801 (f)
All,
I am working with one of my customers to reduce their tape consumption.
Many of their backup versions are being kept at and for No Limit.
I have some general guidelines in mind to propose to each individual
business unit. What I am looking for is a somewhat formatted document
that I
70 matches
Mail list logo
