-----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 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:ads...@vm.marist.edu] On Behalf Of Dwight Cook Sent: Wednesday, April 29, 2009 4:28 PM To: ADSM-L@VM.MARIST.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:ads...@vm.marist.edu] On Behalf Of Bell, Charles (Chip) Sent: Wednesday, April 29, 2009 3:51 PM To: ADSM-L@VM.MARIST.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:ads...@vm.marist.edu] On Behalf Of Dwight Cook Sent: Wednesday, April 29, 2009 3:40 PM To: ADSM-L@VM.MARIST.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:ads...@vm.marist.edu] On Behalf Of Bell, Charles (Chip) Sent: Wednesday, April 29, 2009 2:55 PM To: ADSM-L@VM.MARIST.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
