Hi Maurice - Depends on the situation. The advantage of bringing the imported node back under a different name: You can move it to a different domain where you can set the copy groups so that the data doesn't expire.
If you only plan to have the filespace(s) around long enough to do 1 restore, that wouldn't be necessary; you could just do the import with DATES=RELATIVE, restore from the imported (newly named) filespace, then delete the imported filespace. Wanda -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Maurice van 't Loo Sent: Thursday, September 15, 2005 2:32 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: generate full backup using backupsets Hi Wanda, Why an other node or copygroup? If you use "merge=no" the imported fs's gets an other name, so after the restore you can savely delete the imported fs's.... And "replacedefs=no" is default, so the copygroups don't get changed... Regards, Maurice ----- Original Message ----- From: "Prather, Wanda" <[EMAIL PROTECTED]> To: <ADSM-L@VM.MARIST.EDU> Sent: Wednesday, September 14, 2005 7:38 PM Subject: Re: [ADSM-L] generate full backup using backupsets RTFM for IMPORT - there is an option DATES=RELATIVE. You can use that to control whether files roll off based on their original backup dates, or relative to the date you do the import. However, I think a better solution is usually to isolate the imported node entirely. I'm assuming that you wouldn't be DOING this import on a normal basis - something has to be very damaged for you to want to go get this EXPORT and deal with it (and the impact on your DB). If I wanted to bring back a huge export for NODEA, what I would do is: 1) RENAME the current NODEA to NODEA-TEMP. Do the IMPORT with DATES=RELATIVE. COPY the current policy domain to a new policy domain called REBUILT_STUFF. Set the copy groups in REBUILT_STUFF to NEVER expire. Rename the imported NODEA to NODEA-REBUILT Move NODEA into the REBUILT_STUFF policy domain. Rename NODEA-TEMP to NODEA. That way you have all the current data for NODEA available, and the rebuilt NODEA as well. You don't have to worry about versions expiring or being replaced. 2) And even BETTER solution would probably be to create a second instance of your TSM server (on the same host is fine), with it's own DB, and do the import into that with DATES=RELATIVE. That way it wouldn't matter how long the IMPORT takes, or clutter up your production DB. Wanda Prather "I/O, I/O, It's all about I/O" -(me) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kurt Beyers Sent: Wednesday, September 14, 2005 10:19 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: generate full backup using backupsets Thanks for the feedback so far. An archive is out of question due to the 'schedule maintenance' that would be required as William pointed out and due to the bandwith anyway. But the 'export node' mentioned by Maurice is a possibility that I will try out further. A good suggestion tht I didn't think yet of. What happens if the data on the export expires in the TSM database due to the management class it is bound to. Can it still be imported and bound to a new management class? best regards, Kurt ________________________________ Van: ADSM: Dist Stor Manager namens William Boyer Verzonden: wo 14/09/2005 13:13 Aan: ADSM-L@VM.MARIST.EDU Onderwerp: Re: [ADSM-L] generate full backup using backupsets If you want to maintain all the schedules that go with the correct node with the correct drive letters for his 75 nodes.... And when an admin adds a drive to a node without letting you know? Or removes one and now your schedules fail because D:\*.* doesn't exist? Whose fault does that end up being when they can't restore the data you said you were archiving for them? And if your requirements are that you be able to BMR a box to a monthly state, archive is out of the question. I would sooner use archive, don't get me wrong, but there's just not a DOMAIN that you can specify to archive and have it pick up everything in that DOMAIN. Like backup. With changes when those pesky admins change things and don't communicate it back to you. Bill Boyer "Some days you're the bug, some days you're the windshield" - ?? -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Stapleton, Mark Sent: Tuesday, September 13, 2005 9:53 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: generate full backup using backupsets From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of William Boyer >I would very much like to use an ARCHIVE for this, but haven't figured >out how to make it do all drives without having to code them in a >command script or in the OBJECT= for the schedule. ...and the problem with that is...? -- Mark Stapleton ([EMAIL PROTECTED]) IBM Certified Advanced Deployment Professional Tivoli Storage Management Solutions 2005 IBM Certified Advanced Technical Expert (CATE) AIX Office 262.521.5627
