JBB backed-up inspected
Our TSM servers are on RHEL6, and run server version 6.3.4. They have 128 GB RAM available. We have two Windows 2012 R2 servers running the 6.4.0.0 client. They both run DFS-R, replicating data from two corresponding servers at our offsite data center. The two servers have recently been setup to use Journal Based Backups. The two servers at the offsite data center are not using JBB, but if it is successfull on the local two servers the plan is to implement JBB on the offsite servers also. The incremental backups of the two WIndows servers had been running unusually long. Six to eight hours, sometimes much more, while scanning only 3 1/2 million files. And, they backup only a few hundred files. Both have 4 GB of RAM. They are virtual machines on ESX. The new elapsed times have been 4 minutes, 16 minutes, etc. So run times are greatly improved. Here's my question: both Windows servers are backing up more objects than they are inspecting! For example: objects inspected 2,840, objects backed up: 4,101, objects expired: 707. What does that mean? Could it be that several new files were created after the start of the backup, so they were backed up immediatly, without entries being made in the journal? If that's the scenario, the journal contained 2840 entries for new/updated objects, maybe 707 entries for deleted ojects, and 1,261 objects were added or updated after the start of the backup. I have no previous JBB experience, so I'm just guessing at what's happening. If someone has seen that behavior before, and has a good understanding of the cause I would be grateful to hear from you. With my thanks and best wishes, Keith Arbogast Indiana University
Re: Bandwidth
If the switch-to-server links are saturated, you can gang several of them together with etherchannel. It's too easy to blame the network for everything, including inadequately cold soda in the vending machine. So before blaming the network, make sure that the TSM server processor is not the actual bottleneck. I have also relieved what appeared to be network bottlenecks by adding TSM server memory. We have also seen bottlenecks in the links to the TSM server's disk subsystem. If these kinds of server issues are the bottleneck, dedup will just make it worse. And as usual, remember that each time you remove a bottleneck, you just expose another one - which could actually be the network. If you can't back up as much as you want, look at the whole system, not just the network. Roger Deschner University of Illinois at Chicago rog...@uic.edu On Thu, 15 May 2014, Tom Taylor wrote: Thanks for all the advice, I am talking about WAN traffic. Thomas Taylor System Administrator Jos. A. Bank Clothiers Cell (443)-974-5768 From: Bent Christensen b...@cowi.dk To: ADSM-L@VM.MARIST.EDU, Date: 05/15/2014 08:54 AM Subject: Re: [ADSM-L] Bandwidth Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Hi Thomas, Just to be sure, are you talking about LAN or WAN backup traffic? Is your bottleneck in the TSM-client-to-switch connection or the switch-to-tsm-server connection? If TSM is saturating your WAN lines, looking into dedup and compression is the best you can do. If your problem is within a LAN you might have to reconsider your backbone and network design, if that is not an option spreading the client start times might do the trick. But there is no such thing in TSM as bandwidth throttling like in i.e. Symantec Netbackup. - Bent -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Tom Taylor Sent: Wednesday, May 14, 2014 5:56 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Bandwidth Good morning, I run TSM 6.3.4 How do I throttle bandwidth so that the clients don't choke the network during backups. I have already set a large window for the clients to use, and I am reading about client side de-duplication, and adaptive file backup. Are these the only two avenues to reduce the bandwidth used by TSM? Thomas Taylor System Administrator Jos. A. Bank Clothiers Cell (443)-974-5768
TSM 7.1 upgrade
We are testing the upgrade from 6.2 to 7.1 and we get this error when starting TSM on the test server after the upgrade. ANR0103E admnode.c(25990): Error 2343 updating row in table Nodes. ANRD_1490373789 AdmConvertNodeAttrs(admnode.c:25815) Thread1: Error 2343 converting the attributes for node ServerA The server is an NT 4.0 server running the 5.1.0.0 agent. (keep the chuckles to a minimum please) Does anyone know of a fix? I am also calling IBM. Andy Huebner
Re: JBB backed-up inspected
I am facing the same problem on Windows 2012 with TSM Client 7.1, but I couldn't explain this. Maybe rest of objects is coming from SYSTEMSTATE? Grigori Solonovitch, Senior Systems Architect, IT, Ahli United Bank Kuwait, www.ahliunited.com.kw -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Arbogast, Warren K Sent: 16 05 2014 4:17 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] JBB backed-up inspected Our TSM servers are on RHEL6, and run server version 6.3.4. They have 128 GB RAM available. We have two Windows 2012 R2 servers running the 6.4.0.0 client. They both run DFS-R, replicating data from two corresponding servers at our offsite data center. The two servers have recently been setup to use Journal Based Backups. The two servers at the offsite data center are not using JBB, but if it is successfull on the local two servers the plan is to implement JBB on the offsite servers also. The incremental backups of the two WIndows servers had been running unusually long. Six to eight hours, sometimes much more, while scanning only 3 1/2 million files. And, they backup only a few hundred files. Both have 4 GB of RAM. They are virtual machines on ESX. The new elapsed times have been 4 minutes, 16 minutes, etc. So run times are greatly improved. Here's my question: both Windows servers are backing up more objects than they are inspecting! For example: objects inspected 2,840, objects backed up: 4,101, objects expired: 707. What does that mean? Could it be that several new files were created after the start of the backup, so they were backed up immediatly, without entries being made in the journal? If that's the scenario, the journal contained 2840 entries for new/updated objects, maybe 707 entries for deleted ojects, and 1,261 objects were added or updated after the start of the backup. I have no previous JBB experience, so I'm just guessing at what's happening. If someone has seen that behavior before, and has a good understanding of the cause I would be grateful to hear from you. With my thanks and best wishes, Keith Arbogast Indiana University Please consider the environment before printing this Email. CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail message and any attachments hereto may be legally privileged and confidential. The information is intended only for the recipient(s) named in this message. If you are not the intended recipient you are notified that any use, disclosure, copying or distribution is prohibited. If you have received this in error please contact the sender and delete this message and any attachments from your computer system. We do not guarantee that this message or any attachment to it is secure or free from errors, computer viruses or other conditions that may damage or interfere with data, hardware or software.
