Restart TSM Scheduler on Ubuntu
Hi people , First i kill all the process with dsmcad (5 dsmcad launch...) After that i do dsmcad sched start And i have this message test@node_name:~# dsmcad sched startd 28.02.2014 09:27:15 (dsmcad) ANSE amsgrtrv.cpp(3087): Message No 11000 could not be found. 28.02.2014 09:27:15 (dsmcad) ANSE amsgrtrv.cpp(3087): Message No 11000 could not be found. 28.02.2014 09:27:15 (dsmcad) ANS0102W Unable to open the message repository /opt/tivoli/tsm/client/ba/bin/fr_FR/dsmclientV3.cat. The American English repository will be used instead. But on my TSM Server i see the ANR0406I Session 28037 started for node NODE_NAME (Linux86) (Tcp/Ip blabla.fr(60250)). ANR0403I Session 28037 ended for node NODE_NAME (Linux86). But each day the node was missed anybody (nothing in the dsmerror.log and in the dsmsched.log).. Best regards, Mickael. +-- |This was sent by bobpatrick808...@yahoo.fr via Backup Central. |Forward SPAM to ab...@backupcentral.com. +--
Tangent: ESX, Linux, and Backups
I apologize for introducing a tangent, but I need some help defining a problem. Those of us who have studied (or used!) TSM for VE know that the TDP for SQL Server can receive a signal from Windows Server that something is about to take a backup. The same signal should trigger any pending writes before something takes a snapshot and then backs up a restorable disk image. Are there similar signals (which might not be the right word) in Linux or various UNIX systems? Assuming a lack of support from an application vendor, I'd want at least to fire off a script upon receiving that signal to use existing commands to "freeze" the app, Are there better idioms I should use with my Linux/UNIX gurus, or is this simply not an option yet? Thanks, Nick
Re: TSM for desktop backups
>>Has anyone had experience using TSM to backup desktop machines? Did it years ago for about 200 Windows desktops. Turned on subfile backup, worked a treat. (No experience with MACs.) Didn't have a good way to deal with the overnight power down issues at the time, so backed up desktops during the day, servers at night. Really. Amount of data so small compared to email, downloads, Lolcats, Youtube, nobody in the network group even noticed. >>Do the end users understand how to restore files using the GUI? Yes. I think most people find the interface pretty intuitive, except for the "view active/inactive", which you have to explain several times, then they get it. >>If a desktop machine is used by multiple login accounts at different times, >>does the TSM GUI allow a client to only view/restore their own files? It used to on Windows. Dunno about MACs, and haven't tested on Windows 7 or 8. Better verify. If it doesn't I think you could open a PMR, don't know what response you'd get. >>What issues did you have to overcome? 1. pst files. They are evil for backup and almost insurmountable. Exterminate them. 2. Pushing out new client versions. Best done with something like Endpoint manager, or whatever else you normally distribute desktop software with. 3. Subfile backup helps a lot. Really. 4. Up through Win2K3, we had a fairly straightforward way of doing a BMR with the basic TSM client, even to different hardware. These days, you better take a look at the supported Bare Metal restore procedure for Windows with the TSM client. It is about a 17 step process with a very high learning curve and low probability of success. If these desktops may require BMR, I'd advise to use something else. 5. These days, before deciding I'd do a survey and see how many of your "desktops" are really docking stations for laptops that leave the building at night. Using the basic TSM client requires machines to be available when their schedule fires, and not driving down the interstate. If they are actually mobile, use a product like Fastback for Workstations (formerly known as CDP for Files) that does continuous coverage and is designed for occasionally-connected machines. (It backs up files to a local repository as they are closed, then uploads the backups to the TSM server when a connection is available.) 6. Also had some experience with Fastback for Workstations (formerly known as CDP for files). I actually don't think it's as intuitive as the basic client, but as I said before, it's designed for continuous coverage and occasionally-connected backups. Minor thing to think about, you'll be getting slow, sometimes long-running backups of laptops at all hours of the day. You won't ever have a "window" when the TSM server doesn't have backups running. If that bothers you, plan on a separate TSM server. 7. If this is a hand full of desktops, it's a trivial thing for TSM admins to support. But since you are looking at other products I assume it's more than a handful. Consider then your personnel resources. When I've looked recently, a cloud service is more economical. Not only do you not have to build out the hardware for the support, but *they* provide the end-user support. W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of David Jelinek Sent: Thursday, February 27, 2014 10:37 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM for desktop backups We have used TSM for our Enterprise backups of our servers for many years. We are now considering backing up our end-user desktop machines, but only the user folders. Has anyone had experience using TSM to backup desktop machines? What issues did you have to overcome? Do the end users understand how to restore files using the GUI? If a desktop machine is used by multiple login accounts at different times, does the TSM GUI allow a client to only view/restore their own files? We are concerned with both Windows and Macs. Does anyone know of a feature matrix comparison of TSM and Crashplan? Thanks in advance. -- Have a wonderful day, David Jelinek
Re: Tangent: ESX, Linux, and Backups
Nick, if you don't have a TDP for the app, you can still use the PRESCHEDCOMMAND and POSTSCHEDCOMMAND options of the B/A-client. if you have a VM, the VMware-API gives you a similar hook: **/usr/sbin/pre-freeze-script /usr/sbin/post-thaw-script -- Mit freundlichen Grüßen / Kind regards Michael Prix On 02/28/2014 03:14 PM, Nick Laflamme wrote: > I apologize for introducing a tangent, but I need some help defining a > problem. > > Those of us who have studied (or used!) TSM for VE know that the TDP for > SQL Server can receive a signal from Windows Server that something is about > to take a backup. The same signal should trigger any pending writes before > something takes a snapshot and then backs up a restorable disk image. > > Are there similar signals (which might not be the right word) in Linux or > various UNIX systems? Assuming a lack of support from an application > vendor, I'd want at least to fire off a script upon receiving that signal > to use existing commands to "freeze" the app, > > Are there better idioms I should use with my Linux/UNIX gurus, or is this > simply not an option yet? > > Thanks, > Nick
Re: Tangent: ESX, Linux, and Backups
What B/A client? :-) If I take my backups at the ESX level, I'm trying to do just an image backup, driven by ESX, not using some client in the virtual machine. So, I need Linux to catch the signal from ESX of an impending snapshot, and I need a way for Linux to trigger those pre- and post- command scripts. That is my goal. On Friday, February 28, 2014, Michael Prix wrote: > Nick, > > if you don't have a TDP for the app, you can still use the > PRESCHEDCOMMAND and POSTSCHEDCOMMAND options of the B/A-client. > > if you have a VM, the VMware-API gives you a similar hook: > **/usr/sbin/pre-freeze-script > /usr/sbin/post-thaw-script > > -- > Mit freundlichen Grüßen / Kind regards > > Michael Prix > > On 02/28/2014 03:14 PM, Nick Laflamme wrote: > > I apologize for introducing a tangent, but I need some help defining a > > problem. > > > > Those of us who have studied (or used!) TSM for VE know that the TDP for > > SQL Server can receive a signal from Windows Server that something is > about > > to take a backup. The same signal should trigger any pending writes > before > > something takes a snapshot and then backs up a restorable disk image. > > > > Are there similar signals (which might not be the right word) in Linux or > > various UNIX systems? Assuming a lack of support from an application > > vendor, I'd want at least to fire off a script upon receiving that signal > > to use existing commands to "freeze" the app, > > > > Are there better idioms I should use with my Linux/UNIX gurus, or is this > > simply not an option yet? > > > > Thanks, > > Nick >
Re: Tangent: ESX, Linux, and Backups
Op 28 feb. 2014, om 19:08 heeft Nick Laflamme het volgende geschreven: > What B/A client? :-) > > If I take my backups at the ESX level, I'm trying to do just an image > backup, driven by ESX, not using some client in the virtual machine. > > So, I need Linux to catch the signal from ESX of an impending snapshot, and > I need a way for Linux to trigger those pre- and post- command scripts. > That is my goal. maybe you need to study the vmware tools for linux This has nothing to do with TSM... > > On Friday, February 28, 2014, Michael Prix wrote: > >> Nick, >> >> if you don't have a TDP for the app, you can still use the >> PRESCHEDCOMMAND and POSTSCHEDCOMMAND options of the B/A-client. >> >> if you have a VM, the VMware-API gives you a similar hook: >> **/usr/sbin/pre-freeze-script >> /usr/sbin/post-thaw-script >> >> -- >> Mit freundlichen Grüßen / Kind regards >> >> Michael Prix >> >> On 02/28/2014 03:14 PM, Nick Laflamme wrote: >>> I apologize for introducing a tangent, but I need some help defining a >>> problem. >>> >>> Those of us who have studied (or used!) TSM for VE know that the TDP for >>> SQL Server can receive a signal from Windows Server that something is >> about >>> to take a backup. The same signal should trigger any pending writes >> before >>> something takes a snapshot and then backs up a restorable disk image. >>> >>> Are there similar signals (which might not be the right word) in Linux or >>> various UNIX systems? Assuming a lack of support from an application >>> vendor, I'd want at least to fire off a script upon receiving that signal >>> to use existing commands to "freeze" the app, >>> >>> Are there better idioms I should use with my Linux/UNIX gurus, or is this >>> simply not an option yet? >>> >>> Thanks, >>> Nick >> -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Tangent: ESX, Linux, and Backups
Hello Nick, well, if you use the TDP for VE, or "backup vm", then the pre-freeze/post-thaw is what you want. These scripts are invoked by the vmware-tools, which must be installed in the vm. http://support.unitrends.com/ikm/questions.php?questionid=1241 -- Mit freundlichen Grüßen / kind regards Michael Prix On 02/28/2014 07:08 PM, Nick Laflamme wrote: > What B/A client? :-) > > If I take my backups at the ESX level, I'm trying to do just an image > backup, driven by ESX, not using some client in the virtual machine. > > So, I need Linux to catch the signal from ESX of an impending snapshot, and > I need a way for Linux to trigger those pre- and post- command scripts. > That is my goal. > > On Friday, February 28, 2014, Michael Prix wrote: > >> Nick, >> >> if you don't have a TDP for the app, you can still use the >> PRESCHEDCOMMAND and POSTSCHEDCOMMAND options of the B/A-client. >> >> if you have a VM, the VMware-API gives you a similar hook: >> **/usr/sbin/pre-freeze-script >> /usr/sbin/post-thaw-script >> >> -- >> Mit freundlichen Grüßen / Kind regards >> >> Michael Prix >> >> On 02/28/2014 03:14 PM, Nick Laflamme wrote: >>> I apologize for introducing a tangent, but I need some help defining a >>> problem. >>> >>> Those of us who have studied (or used!) TSM for VE know that the TDP for >>> SQL Server can receive a signal from Windows Server that something is >> about >>> to take a backup. The same signal should trigger any pending writes >> before >>> something takes a snapshot and then backs up a restorable disk image. >>> >>> Are there similar signals (which might not be the right word) in Linux or >>> various UNIX systems? Assuming a lack of support from an application >>> vendor, I'd want at least to fire off a script upon receiving that signal >>> to use existing commands to "freeze" the app, >>> >>> Are there better idioms I should use with my Linux/UNIX gurus, or is this >>> simply not an option yet? >>> >>> Thanks, >>> Nick
