Re: More files in copy pool than primary pool?
On 12/06/2012 11:19 AM, Ehresman,David E. wrote: > No move data involved. > > In fact, the problem persists after deleting all the copy pool volumes for > this node and doing a fresh backup stg. > If you're doing that level of evaluation, then I suggest you q contents for the node on the various volumes, and reconcile them. - Allen S. Rout
Re: Backing up desktops/workstations
A separate server seems reasonable if you have thousands of nodes, even if there's only a few files per node. I'd be a bit nervous about excluding media files, since there can be legitimate uses for them depending on the user. Maybe you could have an opt-in for backing those up, with a signed form on file stating that the user will store non-work media files in a non-backed up location? We've side-stepped this issue by generally not backing up desktops[1]. If a user wants files backed up, the policy is that they should end up on a file server we do back up. [1] Our desktop support team does offer limited backups of desktops and laptops via Iron Mountain's Autonomy service. I would have preferred TSM, but I can't complain since I'm not involved with it at all. It seems to work adequately, although it's somewhat expensive and very slow on the restore side. -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine On 12/10/12 07:42 AM, Zoltan Forray wrote: I am looking for war-stories, experiences, suggestions, ideas from you folks that have implemented backing up desktop machines, which could expand into thousands of additional TSM nodes. I have been tasked with looking into doing this. The current guidelines is to "only backup 'documents and settings/users' folder, excluding all music files (mp3/wmv/wav/flac/ogg)". My first thought is to stand-up a new server (or two). Create a default policy-domain with short retention (30-days or less) with few copies (2) and a cloptset with an exclude everything and include doc & settings/users plus exclude or the music files. -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: More files in copy pool than primary pool?
What is retention set on copy pools versus primary pools ? -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@vm.marist.edu] On Behalf Of Allen S. Rout Sent: Monday, December 10, 2012 8:42 AM To: ADSM-L@vm.marist.edu Subject: Re: [ADSM-L] More files in copy pool than primary pool? On 12/06/2012 11:19 AM, Ehresman,David E. wrote: > No move data involved. > > In fact, the problem persists after deleting all the copy pool volumes for > this node and doing a fresh backup stg. > If you're doing that level of evaluation, then I suggest you q contents for the node on the various volumes, and reconcile them. - Allen S. Rout
Backing up desktops/workstations
I am looking for war-stories, experiences, suggestions, ideas from you folks that have implemented backing up desktop machines, which could expand into thousands of additional TSM nodes. I have been tasked with looking into doing this. The current guidelines is to "only backup 'documents and settings/users' folder, excluding all music files (mp3/wmv/wav/flac/ogg)". My first thought is to stand-up a new server (or two). Create a default policy-domain with short retention (30-days or less) with few copies (2) and a cloptset with an exclude everything and include doc & settings/users plus exclude or the music files. -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: Backing up desktops/workstations
One idea might be to adopt a 2-pronged approach. On the client side, use USMT (for Microsoft, I'm not sure what you would use for Linux or other platforms) to have the Client PCs submit an archive file up to a network share. This way, you don't have to worry about TSM schedules for all the desktops/workstations -- client PC uploads a ZIP or similar file on a schedule that suits your needs. Maybe once a week. On the server side, then just add the new fileserver/fileshare that contains these archives to your backup routine. Then it's just backing up another server, and you're not concerned about the impact of trying to schedule the backup of computers where files may be in use, or the computers aren't on, etc. etc. etc. Best regards, Michael Ryder Senior Systems Infrastructure Administrator Roche Molecular Systems, Inc. Information Technology 1080 US Highway 202S Building 500/2532 Branchburg, NJ 08876-3733, USA Phone: +1 908 253 7942 Fax: +1 908 253 7651 mailto: michael_s.ry...@roche.com www.roche.com Confidentiality Note: This message is intended only for the use of the named recipient(s) and may contain confidential and/or proprietary information. If you are not the intended recipient, please contact the sender and delete this message. Any unauthorized use of the information contained in this message is prohibited. -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Monday, December 10, 2012 10:42 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Backing up desktops/workstations I am looking for war-stories, experiences, suggestions, ideas from you folks that have implemented backing up desktop machines, which could expand into thousands of additional TSM nodes. I have been tasked with looking into doing this. The current guidelines is to "only backup 'documents and settings/users' folder, excluding all music files (mp3/wmv/wav/flac/ogg)". My first thought is to stand-up a new server (or two). Create a default policy-domain with short retention (30-days or less) with few copies (2) and a cloptset with an exclude everything and include doc & settings/users plus exclude or the music files. -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: Backing up desktops/workstations
In our environment we have each of users setup with an individual network share on a server. We then had everyone's "My Documents" folder mapped to their network share. We ask that the user not keep "valuables" on their local pc and keep it on mapped drives. That way all the users files are sitting on a server and not on the desktop. We then have assorted excludes to help reduce the mp3 and other files. If the user is required to work with mp3 or other files then they keep those files in a separate mapped drive related to the department they are working in. Instead of backing up countless desktops and related issues we just back a couple of servers. David Tyree Interface Analyst South Georgia Medical Center 229.333.1155 -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Monday, December 10, 2012 10:42 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Backing up desktops/workstations I am looking for war-stories, experiences, suggestions, ideas from you folks that have implemented backing up desktop machines, which could expand into thousands of additional TSM nodes. I have been tasked with looking into doing this. The current guidelines is to "only backup 'documents and settings/users' folder, excluding all music files (mp3/wmv/wav/flac/ogg)". My first thought is to stand-up a new server (or two). Create a default policy-domain with short retention (30-days or less) with few copies (2) and a cloptset with an exclude everything and include doc & settings/users plus exclude or the music files. -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: Backing up desktops/workstations
This is very true. One of the things I forgot to mention is that we used to backup desktops. We're mostly in the research computing business, so we "only" had around 100 desktops and laptops we backed up. That said, the overhead of checking to see why that system failed its backups was high - in many cases the desktop would be powered off, or the user would have taken the laptop home. The staff overhead of figuring out why each backup failed was high, and we ended up letting a bunch of the failures slide. At that point, it raised the question of why we were expending so much time and money trying to back those systems up, when we couldn't find the time to figure out why they failed. Unless you have a good way to ensure the backups are actually valid, complete, and timely, the value of backing those systems up is questionable. -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine On 12/10/12 10:15 AM, Rick Adamson wrote: With the higher probability of workstations being susceptible to data loss, compared to servers in a secure data center, either from a system failure and/or reload, our company decided that using a domain policy which redirects the Documents and Settings folder (as well as newer OS's "Users" folder) to a file server. Their official position is that you NEVER keep business data on a workstation device. Ultimately this saves a significant amount of money in storage and licenses. Additionally, this practice lowers the cost of the desktop support team managing end-user systems. They no longer need to be concerned about business data when performing OS reloads/upgrades. HTH ~Rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Monday, December 10, 2012 10:42 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Backing up desktops/workstations I am looking for war-stories, experiences, suggestions, ideas from you folks that have implemented backing up desktop machines, which could expand into thousands of additional TSM nodes. I have been tasked with looking into doing this. The current guidelines is to "only backup 'documents and settings/users' folder, excluding all music files (mp3/wmv/wav/flac/ogg)". My first thought is to stand-up a new server (or two). Create a default policy-domain with short retention (30-days or less) with few copies (2) and a cloptset with an exclude everything and include doc & settings/users plus exclude or the music files. -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: Backing up desktops/workstations
With the higher probability of workstations being susceptible to data loss, compared to servers in a secure data center, either from a system failure and/or reload, our company decided that using a domain policy which redirects the Documents and Settings folder (as well as newer OS's "Users" folder) to a file server. Their official position is that you NEVER keep business data on a workstation device. Ultimately this saves a significant amount of money in storage and licenses. Additionally, this practice lowers the cost of the desktop support team managing end-user systems. They no longer need to be concerned about business data when performing OS reloads/upgrades. HTH ~Rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Zoltan Forray Sent: Monday, December 10, 2012 10:42 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Backing up desktops/workstations I am looking for war-stories, experiences, suggestions, ideas from you folks that have implemented backing up desktop machines, which could expand into thousands of additional TSM nodes. I have been tasked with looking into doing this. The current guidelines is to "only backup 'documents and settings/users' folder, excluding all music files (mp3/wmv/wav/flac/ogg)". My first thought is to stand-up a new server (or two). Create a default policy-domain with short retention (30-days or less) with few copies (2) and a cloptset with an exclude everything and include doc & settings/users plus exclude or the music files. -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html
Re: Backing up desktops/workstations
On 10 dec. 2012, at 20:41, Skylar Thompson wrote: > This is very true. One of the things I forgot to mention is that we used > to backup desktops. We're mostly in the research computing business, so > we "only" had around 100 desktops and laptops we backed up. That said, > the overhead of checking to see why that system failed its backups was > high - in many cases the desktop would be powered off, or the user would > have taken the laptop home. There are two ways about this. One is to implement CDP for files: http://www-01.ibm.com/software/tivoli/products/continuous-data-protection/ The other way is to allow users to backup to TSM from their workstation, but make them responsible for it. Just give them an node account, and tell them to use it, but do not schedule the backups. Of course, there is no guarantee that a user has a recent backup of his files when he needs to restore, but at least you've provided him with a way of protecting himself. As for not having any data on the workstation, that is in some circumstances close to impossible, for example for laptop/mobile users. Having an irregular backup is better than no backup at all, and having a user be aware of his role in protecting his and the company's data is always a good thing. -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Backing up desktops/workstations
On 12/10/12 02:48 PM, Remco Post wrote: On 10 dec. 2012, at 20:41, Skylar Thompson wrote: This is very true. One of the things I forgot to mention is that we used to backup desktops. We're mostly in the research computing business, so we "only" had around 100 desktops and laptops we backed up. That said, the overhead of checking to see why that system failed its backups was high - in many cases the desktop would be powered off, or the user would have taken the laptop home. There are two ways about this. One is to implement CDP for files: http://www-01.ibm.com/software/tivoli/products/continuous-data-protection/ The other way is to allow users to backup to TSM from their workstation, but make them responsible for it. Just give them an node account, and tell them to use it, but do not schedule the backups. Of course, there is no guarantee that a user has a recent backup of his files when he needs to restore, but at least you've provided him with a way of protecting himself. As for not having any data on the workstation, that is in some circumstances close to impossible, for example for laptop/mobile users. Having an irregular backup is better than no backup at all, and having a user be aware of his role in protecting his and the company's data is always a good thing. I actually did bring up using CDP as a solution at the time, but it ended up coming down to a matter of costs and staffing - if research computing offered it as a solution, we'd have to pay for it and support it using our own resources. We decided that desktop support simply wasn't one of our core competencies (mass storage/archiving, high-performance computing, etc.), and left the matter with our desktop folks to solve. We also did briefly consider allowing our end users to be responsible for backups but I think that would be a recipe for them never happening. In academia, CYA is key. :) -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
Re: Backing up desktops/workstations
I've successfully used TSM to back up workstations for a customer. But these were true desktops that did not leave the building. They were stationary and always on the network, which lets the normal TSM scheduling modes work well for them; there's really no difference in backing up servers vs workstations, in that case. Once you get laptops and other "occasionally connected" devices involved, the normal TSM scheduling is a problem, you probably only want to back up documents but not the OS, and "continuous protection" is more likely desirable. But you still don't want to leave it up to the user. (If you've decided there is a need to spend time and money to make backups possible, it must mean you have a reason to make them effective). That really changes the paradigm, and as big a fan as I am of TSM, I think something other than the standard client is a better idea. I have one customer who is successfully using TSM CDP. I'd sure recommend using a separate TSM server for that, as you have stuff connecting and backing up 24 hours a day, and makes it difficult to get things like Expiration to complete in a timely manner when you never have an "empty" window for housekeeping. I think CDP is pretty simple, not a lot of controls. If I got to choose, the first thing I would look at is Fastback for Workstations, which is has design points to deal with these issues and has some interesting sophisticated features. But, I've never personally used it, so just take that as a recommendation to investigate. W -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Skylar Thompson Sent: Monday, December 10, 2012 6:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Backing up desktops/workstations On 12/10/12 02:48 PM, Remco Post wrote: > On 10 dec. 2012, at 20:41, Skylar Thompson wrote: > >> This is very true. One of the things I forgot to mention is that we >> used to backup desktops. We're mostly in the research computing >> business, so we "only" had around 100 desktops and laptops we backed >> up. That said, the overhead of checking to see why that system failed >> its backups was high - in many cases the desktop would be powered >> off, or the user would have taken the laptop home. > > > There are two ways about this. One is to implement CDP for files: > http://www-01.ibm.com/software/tivoli/products/continuous-data-protect > ion/ > > The other way is to allow users to backup to TSM from their workstation, but > make them responsible for it. Just give them an node account, and tell them > to use it, but do not schedule the backups. Of course, there is no guarantee > that a user has a recent backup of his files when he needs to restore, but at > least you've provided him with a way of protecting himself. > > As for not having any data on the workstation, that is in some circumstances > close to impossible, for example for laptop/mobile users. Having an irregular > backup is better than no backup at all, and having a user be aware of his > role in protecting his and the company's data is always a good thing. > I actually did bring up using CDP as a solution at the time, but it ended up coming down to a matter of costs and staffing - if research computing offered it as a solution, we'd have to pay for it and support it using our own resources. We decided that desktop support simply wasn't one of our core competencies (mass storage/archiving, high-performance computing, etc.), and left the matter with our desktop folks to solve. We also did briefly consider allowing our end users to be responsible for backups but I think that would be a recipe for them never happening. In academia, CYA is key. :) -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine
VE 6.4 Testing - think & thin
Testing VE 6.4 on TSM server 6.3.2 Win2K64. ESX hosts are VSphere 5. So on the first VE backup we see as expected: 12/10/2012 05:18:22 TSM for Virtual Environments TDP VMware 6.4.0.00 12/10/2012 05:19:01 ANS1711W Incremental backup selected for 'H', but a Full backup has not yet been performed. Performing a Full backup instead. . Then we see . . 12/10/2012 05:20:14 ANS9384W Unable to get VMware Changed Block Tracking(CBT) data for virtual machine 'H'. Full VM backup continues, and includes both used and unused areas of the disk. The "unable to get VMWare CBT data" is also expected on the first backup. But I thought with VE it was supposed to be smart enough not to include unused areas of the disk? We've checked with show VM all: CBT is enabled, and subsequent backups are true incrementals. We've also tried blowing the filespace away and starting over with the same VM, same results. The problem is that these are thin-provisioned disks. When you get this first full including all the unused space, then when you restore the VM, it comes back as full sized, no longer thin-provisioned, with the possibility of blowing out the datastore and causing a nasty outage. Anybody got a solution? Wanda Wanda Prather | Senior Technical Specialist | wanda.prat...@icfi.com | www.icfi.com ICF International | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | 410.539.1135 (o)