No no, I'm saying that when someone needs a restore, it can be difficult to find the VM if it moved.
In other words, if I have backups for the past month and the VM was on datastore 1, but then last week it moved to datastore 2, then when the restore is needed they'll grab it from datastore 2, but if they don't get back what they need, and have to go farther back, there's no record that it was on datastore 1 so they have to go looking for it, which takes extra time (admittedly not a lot, but apparently it's a common enough problem that they want a different solution -- and it has to be a vendor, not an in-house script (don't get me started)). -Adam On Fri, Oct 30, 2015 at 1:12 PM, Michael Ryder <mryder1...@gmail.com> wrote: > Wait a minute... vMotion is allowed to move VMs around, but then your > backup software is expected to put them right back where they were found? > Why would it matter? That... almost doesn't sound fair! > > By default, if vMotion is enabled, vCenter will determine where to place > the VM when it is restored, based on performance of the VMware cluster. > > On Fri, Oct 30, 2015 at 8:33 AM, Adam Levin <levi...@gmail.com> wrote: > >> One of the issues we've been seeing with using NBU with the NetApp is >> that while NBU can orchestrate the snapshot on the NetApp, it doesn't >> catalog which VMs are on which datastores, so if a vMotion occurs and moves >> a VM, and then a restore is required, someone has to go hunt for it. I >> have not experienced this myself, because I'm not operationally in charge >> of the restore process, but I'm told it's a pain. :) >> >> -Adam >> >> On Fri, Oct 30, 2015 at 8:29 AM, Jim Ennis <jim.en...@ucf.edu> wrote: >> >>> We use Netbackup to do API backups of 95% of our virtual machines >>> (VMWARE) down here, in part since our storage backend is Netapp based and >>> has some support for snapshotting/backups. >>> >>> >>> >>> We add an attribute to the VMWARE host description that allows it to use >>> the API backup and it all happens in the background and works well. >>> >>> >>> >>> Jim Ennis >>> >>> Director Systems and Operations >>> >>> University of Central Florida >>> >>> 12716 Pegasus Drive >>> >>> CSB 308 >>> >>> Orlando, FL 32816 >>> >>> >>> >>> E-mail: jim.en...@ucf.edu >>> >>> Voice: 407-823-1701 >>> >>> Fax: 407-882-9017 >>> >>> >>> >>> *From:* tech-boun...@lists.lopsa.org [mailto: >>> tech-boun...@lists.lopsa.org] *On Behalf Of *Adam Levin >>> *Sent:* Thursday, October 29, 2015 5:28 PM >>> *To:* Michael Ryder <mryder1...@gmail.com> >>> *Cc:* tech@lists.lopsa.org >>> *Subject:* Re: [lopsa-tech] backing up your VMs >>> >>> >>> >>> Honestly, NBU isn't a bad product. It's been around a long time, and if >>> you use it in the traditional backup and recovery sense, it works quite >>> well. Its database doesn't scale the way DB2 does, naturally. >>> >>> >>> >>> When we were rebuilding our datacenters 6 years ago, TSM was in the >>> running. We got the new version in to test, and a specialist from IBM came >>> in to configure it in our lab. By the end of the five days, it still >>> wasn't working. NBU was set up and running in about 2 hours. It's not >>> nearly as powerful as a data management platform, and can't scale, but it's >>> ridiculously simple compared to what TSM was. >>> >>> >>> >>> The other issue was that at the time, we were looking at dedupe tech and >>> moving away from tape. TSM just wasn't there yet. NBU was pretty much >>> leading at the time, especially with integration with dedup. >>> >>> >>> >>> And, to be clear, NBU is actually working great in our environment when >>> we use it for traditional client-based backups. It's only the NetApp >>> snapshot integration with VMWare that's lacking, but that's where we want >>> to go. >>> >>> >>> >>> -Adam >>> >>> >>> >>> On Thu, Oct 29, 2015 at 5:05 PM, Michael Ryder <mryder1...@gmail.com> >>> wrote: >>> >>> I haven't heard *anything* nice about NBU, sorry. >>> >>> >>> >>> Are you able to say why they dropped TSM? The DB2 backend >>> implementation is much tighter now, so database update speed has been >>> vastly improved along with stability. Also implemented in the past 6 years >>> was incremental block-level backup and stable dedupe, which together cut >>> backup times down by 75% and at least halved the space usage. >>> >>> >>> >>> I easily peg the Ethernet and FC infrastructure during block-level >>> incremental image backups. >>> >>> >>> >>> Mike >>> >>> >>> >>> On Thursday, October 29, 2015, Adam Levin <levi...@gmail.com> wrote: >>> >>> Thanks, Mike. We were a TSM shop until we switched to NBU 6 years ago. >>> I don't think they're looking to go back, but there's no question it >>> scales. It's probably the biggest, baddest backup system there is. :) >>> >>> >>> >>> -Adam >>> >>> >>> >>> On Thu, Oct 29, 2015 at 12:11 PM, Michael Ryder <mryder1...@gmail.com> >>> wrote: >>> >>> Adam >>> >>> >>> >>> Have you looked at Tivoli (Now Spectrum Protect)? My environment isn't >>> as large as yours, but from what I've heard it scales well. We use it to >>> backup both Linux and Windows VMs and physical hosts. >>> >>> >>> >>> The add-on Tivoli Data Protector for Virtual Environments is the magic >>> smoke that adds features like block-level incremental backups, instant >>> restores and other goodies. >>> >>> >>> >>> >>> https://www-01.ibm.com/support/knowledgecenter/mobile/#!/SS8TDQ_7.1.3/ve.user/c_ve_overview_tsmnode.html >>> >>> >>> >>> Scaling out involving multiple data movers per vCenter is possible, and >>> there are many ways to tune and filter how they operate, such as max number >>> of simultaneous jobs per datastore, per esxi host, etc. >>> >>> >>> >>> Let me know if you have any questions- I'll try to answer them or can >>> put you in touch with a great Tivoli community where you can find folks >>> with larger installations, more answers etc. >>> >>> >>> >>> Mike >>> >>> >>> >>> On Tuesday, October 27, 2015, Adam Levin <levi...@gmail.com> wrote: >>> >>> Hey all, I've got a question about how you backup your VM environment? >>> >>> >>> >>> We're using vSphere 5.5 and NetApp NAS for datastores. We have about 75 >>> 8TB datastores, and about 2500 VMs. The VMs are not distributed evenly >>> because of service levels associated with the datastores. >>> >>> >>> >>> We're being told by various backup vendors that the main issue is the >>> number of VMs per datastore, because quiescing lots of VMs and then taking >>> a datastore snapshot can produce long wait times when rolling the qieusced >>> images back in to the running VM. >>> >>> >>> >>> Our VM team is telling us that there is no current tool to manage the >>> number of VMs per datastore, just the size of the datastores. >>> >>> >>> >>> So I'm curious what some common methods are for managing backups in a >>> large VM environment. Do you just use agents and backup from within the >>> VM? Do you bother doing app consistent backups of the VMs or just snapshot >>> the datastore and not worry about consistency? Have you found a product >>> that manages qiuescing and snapshots in a reasonable way? >>> >>> >>> >>> We've looked at NetBackup, Commvault and Veeam so far. >>> >>> >>> >>> Thanks, >>> >>> -Adam >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
