pstacy
ADSM.ORG Member
TSM 5.3.4 in an all-Windows environment
We have a number of Windows 2003 servers in remote locations where we have installed CDP (2.2.1.9) to help ensure that documents and other files are backed up as quickly as possible without waiting for the normal overnight backup. We've had troubles with people creating and accidently deleting/corrupting/otherwise losing those files within the same day so the overnight job never got them.
I'm seeing cases where CDP seems to quit for no reason. I was looking at some and they show no file transfers anywhere from the previous week all the way back to the end of May. These servers are primarily file servers for users in those locations so there is always activity everyday.
I check the services screen and the CDP service is set to start automatically but not actually running. I try to "start" but get a message the service may have shut down due to no demand for it to be running. I see this in cases where file transfers are in progress so that tells me this is normal. We have it set up to do local storage of its backups (which are captured by the overnight backup) as well as remote backups to our main DISKPOOL in the case of two servers with better network connection speeds.
These servers can go for several weeks at a time at least without some kind of shutdown or reboot so I'm wondering if anyone else has had this trouble? I was told when I started in with Tivoli late last year that CDP was developed as a tool for people with laptops or otherwise not always connected to their network. It would track files that were added/modified since it was last on the network and, when reconnected, it would back up just those files instead of sweeping the entire laptop/workstation.
Since our servers are always connected, I'm wondering if we're using CDP in a way that wasn't intended? Because our servers are running all the time, perhaps it is not getting some kind of needed "reset"?
Due to the sensitivity and critical nature of much of our users' work, we wanted to have the extra protection of CDP on our remote servers but these cases of CDP quitting for no apparent reason make it unreliable and of limited utility.
We have a number of Windows 2003 servers in remote locations where we have installed CDP (2.2.1.9) to help ensure that documents and other files are backed up as quickly as possible without waiting for the normal overnight backup. We've had troubles with people creating and accidently deleting/corrupting/otherwise losing those files within the same day so the overnight job never got them.
I'm seeing cases where CDP seems to quit for no reason. I was looking at some and they show no file transfers anywhere from the previous week all the way back to the end of May. These servers are primarily file servers for users in those locations so there is always activity everyday.
I check the services screen and the CDP service is set to start automatically but not actually running. I try to "start" but get a message the service may have shut down due to no demand for it to be running. I see this in cases where file transfers are in progress so that tells me this is normal. We have it set up to do local storage of its backups (which are captured by the overnight backup) as well as remote backups to our main DISKPOOL in the case of two servers with better network connection speeds.
These servers can go for several weeks at a time at least without some kind of shutdown or reboot so I'm wondering if anyone else has had this trouble? I was told when I started in with Tivoli late last year that CDP was developed as a tool for people with laptops or otherwise not always connected to their network. It would track files that were added/modified since it was last on the network and, when reconnected, it would back up just those files instead of sweeping the entire laptop/workstation.
Since our servers are always connected, I'm wondering if we're using CDP in a way that wasn't intended? Because our servers are running all the time, perhaps it is not getting some kind of needed "reset"?
Due to the sensitivity and critical nature of much of our users' work, we wanted to have the extra protection of CDP on our remote servers but these cases of CDP quitting for no apparent reason make it unreliable and of limited utility.
