ESX VM's backup to tape library

S

syn3rgyz

Gawd
Joined
Jun 14, 2005
Messages
763
I'm trying to backup VM's that are stored on both local storage and SANs to a dell powervault tl2000. I was asked to do this yesterday, and before that I have never seen a tape drive/library in my life. I'm pretty new to VM's but from googling stuff it seems like ESX does not support directly connecting a tape drive and backing up data.

we are currently running ESX 3.01 using a very simple setup with no Vcenter or anything and I suggested that we should upgrade to 3.5 or 4.0, but they don't have any backups at all of the VM's. Would anyone here suggest some ways to get the VM's onto the tl2000 and if its possible to schedule backups after upgrading ESX?

Another question I have is will it be alright to just upgrade ESX instead of doing a fresh install to keep the configurations and user account infos and would an upgrade affect/wipe out the VM's stored in the local array?
 
Last edited:
nope not backing up any other servers, we have 2 ESX boxes for a dev and test environment. Someone before me was managing the boxes but he left the company a while ago, i noticed that some of the VM's has Veritas Netbackup installed but not all.
 
3.0.1 is EOS, just so you know... :)

VCB would work, direct to the hosts. Export them as v.appliances would work to a desktop.

ESX itself has no backup software built in, and there's no scheduling built in - I suggest VCB with something like netbackup or the like :)
 
if I use VCB would I have to get another server to run it? or can I just run it in a VM on one of the ESX boxes, but wouldnt that making restoring complicated?

Does netbackup only backup data on the VM's or it can do full backup of the VM image itself. Would be great if you can link to some guides I can look at.
 
The powervault is connected to the network through a CAT cable, I assume its not possible for the tape to be connected to the host through the network?

If I use netbackup to schedule backups do I only have to install netbackup on the VM running VCB or do I have to install it on each individual VM?

and does anyone have the answer to my question about upgrade vs fresh install?
 
Ugh. NotBackup.

Don't even waste your time with NotBackup; it does not work properly with Windows hosts, especially if you follow instructions. For the TL2000 your only realistic option is going to be something like TSM integrating with VCB, or simply using TSM clients on the guests. Let me reiterate, NotBackup 6.x will not give you usable backups for system rebuilds, period. You need something else.

I need more information on the PowerVault TL2000. Is it the iSCSI model, SCSI, SAS?
 
TSM with VCB is a pain in the ~ass~ to configure, fwiw - you ahve to mess with the config.js files and all the pre/post command goo, and they don't support namelookup, only IP (which may or may not be good) . If you've already got Netbackup, especially 6.5, it's pretty easy (even more so if you own the built-in integration module and don't have to use the scripts), and works decently well. TSM isn't the only realistic option...

You can't connect the tape to the host, but you could probably connect it to the VM - you do have to store the files locally before streaming to tape, as VCB can't go directly to tape unless it serves as a block device. You only install netbackup on the VCB machine most of the time, not the vms. same for TSM / anything else. VCB works regardless of the guest os - it backs up the actual vmdks.
 
Last edited:
lopoetve said:
TSM with VCB is a pain in the ~ass~ to configure, fwiw - you ahve to mess with the config.js files and all the pre/post command goo, and they don't support namelookup, only IP (which may or may not be good) . If you've already got Netbackup, especially 6.5, it's pretty easy (even more so if you own the built-in integration module and don't have to use the scripts), and works decently well. TSM isn't the only realistic option...
Click to expand...

NotBackup with a Windows server and VCB will not work correctly. No, I will NOT divulge my source on this one. Suffice to say, if you are not later than 6.5.1 - and even if you are - you will require an engineering build. Any attempt to perform recovery or DR from VCB and Not Backup will result in failure. Since the Symantec takeover, you absolutely cannot trust NotBackup at all.
6.0 will only run inside the guests, and is incapable of performing consistent or reliable system level restores on Windows for reasons that level 3 support, three Symantec reps, and a VP were unable or unwilling to explain. Sometimes they work, sometimes they don't. NotBackup is just flat out not supportable in any sane enterprise. It requires four weeks and repeated calls to your rep and his manager to get support from someone who has actually worked with the product at some point in their life.
And I'm willing to bet the OP isn't 6.5.x, because nobody would miss that $100K+ line of rape in the budget.

And no, TSM isn't easy by a long shot. It's not meant to be easy yet, it's not designed to be easy yet. 6.x is such a huge change over 5.5, VCB integration is not the #1 priority. (#1 priority is probably still the database upgrade tools; large databases can still take days to convert.) However, TSM is at least reliable once configured. And your tech support calls don't go to some untrained guy in India reading from a script; if there are issues, you will get very good support, especially on any potential bugs.

You can't connect the tape to the host, but you could probably connect it to the VM - you do have to store the files locally before streaming to tape, as VCB can't go directly to tape unless it serves as a block device. You only install netbackup on the VCB machine most of the time, not the vms. same for TSM / anything else. VCB works regardless of the guest os - it backs up the actual vmdks.
Click to expand...

Here's the problem; nobody supports iSCSI tape drives officially yet, unless I missed a memo. (Goes back to iSCSI being immature, unstable, unpredictable. And the fact that LTO is fed in 256k blocks, which is six kinds of NOT GOING TO WORK on iSCSI.) If he's got the iSCSI model, he's only got a never-ending backup window. Off-siting will be absolutely impossible, regardless of what software or method he uses. I mean, best case the drives are going to sit there shoe-shining 60% of the time. Feeding an LTO4 enough to prevent shoe-shine requires rock stable 90MB/sec before compression, minimum. With compression, I've seen LTO4 to LTO4 reclaims run at 220MB/s for an hour solid. So unless the OP missed a SAS or FC connector hiding on the back of that autoloader, backups are going to be a token gesture anyways.

TSM has two implementation methods, which can be used "instead of" or in parallel. The statement that you only put TSM on the VCB host is misleading. Traditionally, TSM is loaded on VCB and within guests, because VCB integration is immature. People aren't willing to commit to counting on TSM+VCB entirely, for obvious reasons. It's an additional safety measure, in case TSM's VCB section accidentally has been trashing your VMDKs due to a bug. In an ESX 3.0x situation, you would need to put TSM on your guests anyways.

I don't know if the upgrade requires you to wipe your VMDKs, but either way, you do need guest OS level backups at the minimum prior to an upgrade. (Even if things go great, you don't want to be the guy going "well I didn't think we needed them" when it goes wrong.) In theory, I think shutting down and copying the VMDKs off would be sufficient, but Iopoetve would have to be the one to answer any VMDK conversion questions. I've not done a 3.0.x to 3.5 or 4.0 upgrade. There may be restrictions and/or additional steps.
 
I know the point you're talking about with netBackup - generally you can get said build without an issue.
I didn't think iSCSI tape drive - I figured it was just a network tape drive of some kind (NFS/CIFS?). As I only work with the direct attached ones :).

Honestly, I'd go with backupexec - its got the most mature of the integration modules for VCB right now, and gives you pretty solid image level backups, which is one of the high points of using a virt. environment. But, it'll cost you all anew too... :(

Don't just copy the vms off - if you have to, at the very least, convert them to a v.app to avoid issues and save space.
 
I need more information on the PowerVault TL2000. Is it the iSCSI model, SCSI, SAS?
Click to expand...

I believe its the SCSI model, since i was told that theres a SCSI cable behind it that connects to a Solaris box right now.

I could barely understand what you guys are talking about since im still new at this :(
but for now I just want to try and upgrade the two boxes and i can deal with scheduling backups later on

Honestly, I'd go with backupexec - its got the most mature of the integration modules for VCB right now, and gives you pretty solid image level backups, which is one of the high points of using a virt. environment. But, it'll cost you all anew too...

Don't just copy the vms off - if you have to, at the very least, convert them to a v.app to avoid issues and save space.
Click to expand...
I don't have any say in what software / hardware can/should be purchased and netclient is what we have right now on some of the VM's, so i think backupexec is out of the question.

So i assume for now my best option is to just copy the vm's off, but is it possible to just copy it to the tape library if you cant connect the tape library to the esx box? Or am i going to have to buy a external hard drive of some sort and plug it in the USB port and copy it over that way?

Would you mind telling me what v.app is and how i would go about to convert it to that?
 
lopoetve said:
Honestly, I'd go with backupexec - its got the most mature of the integration modules for VCB right now, and gives you pretty solid image level backups, which is one of the high points of using a virt. environment. But, it'll cost you all anew too... :(
Click to expand...

I feel we got juked by Symantec on this one. When we originally purchased our setup, you didn't have to buy the agents. Now we're looking at ~$2500/host, so we still haven't purchased them yet (gonna make the first customer that needs it take the hit).

It does work well for our small setup when I tested it. (Using FC library)
 
syn3rgyz said:
I believe its the SCSI model, since i was told that theres a SCSI cable behind it that connects to a Solaris box right now.

I could barely understand what you guys are talking about since im still new at this :(
but for now I just want to try and upgrade the two boxes and i can deal with scheduling backups later on


I don't have any say in what software / hardware can/should be purchased and netclient is what we have right now on some of the VM's, so i think backupexec is out of the question.

So i assume for now my best option is to just copy the vm's off, but is it possible to just copy it to the tape library if you cant connect the tape library to the esx box? Or am i going to have to buy a external hard drive of some sort and plug it in the USB port and copy it over that way?

Would you mind telling me what v.app is and how i would go about to convert it to that?
Click to expand...

Virtual Appliance - file, export as virtual appliance, save, done :)

I'd manually script up VCB to export the VMs to a proxy, and then copy them to tape from there. I don't know how well VCB will play with 3.0.1 though, it's been a bit.
 
SpaceHonkey said:
I feel we got juked by Symantec on this one. When we originally purchased our setup, you didn't have to buy the agents. Now we're looking at ~$2500/host, so we still haven't purchased them yet (gonna make the first customer that needs it take the hit).

It does work well for our small setup when I tested it. (Using FC library)
Click to expand...

well, you can always use it with the scripts for just the cost - it's only if you want the full integration built in that it costs :-/
 
lopoetve said:
Virtual Appliance - file, export as virtual appliance, save, done :)

I'd manually script up VCB to export the VMs to a proxy, and then copy them to tape from there. I don't know how well VCB will play with 3.0.1 though, it's been a bit.
Click to expand...
is that in VI client? there is no export as virtual appliance option
 
Iopoetve said:
I didn't think iSCSI tape drive - I figured it was just a network tape drive of some kind (NFS/CIFS?). As I only work with the direct attached ones.
Click to expand...
syn3rgyz said:
I believe its the SCSI model, since i was told that theres a SCSI cable behind it that connects to a Solaris box right now.
Click to expand...

This is me, breathing a sigh of relief, and also dreading it. I'm guessing that nobody there knows Solaris? No question there was an incomplete NotBackup setup in place now. The question is now, can we put together something that works.

There's no such thing as a NFS/CIFS tape library; if there is, I'm going to start shooting people. Seriously. If iSCSI doesn't work, why would NFS/CIFS? (On a hierarchical system, doing NFS/CIFS to the gateway, sure. On a tape library or autoloader? Oh hell no.)

I could barely understand what you guys are talking about since im still new at this :(
but for now I just want to try and upgrade the two boxes and i can deal with scheduling backups later on
Click to expand...

Don't sweat it. Iopoetve and I jump way ahead (and often off-topic) frequently. It takes us a bit to come back down to earth sometimes. I also tend to jump way ahead. Usually if I get confusing, you can figure out which words to Google for enlightenment. (Or just ask me to explain it in English.) ;)

I don't have any say in what software / hardware can/should be purchased and netclient is what we have right now on some of the VM's, so i think backupexec is out of the question.
Click to expand...

Yeah, this is going to be a real problem. I would honestly be going to management and telling them to either give you a seat at the table on software/hardware purchases, or put the person who's got the say in charge. You can't do what they're asking without a say in the software and hardware.

So i assume for now my best option is to just copy the vm's off, but is it possible to just copy it to the tape library if you cant connect the tape library to the esx box? Or am i going to have to buy a external hard drive of some sort and plug it in the USB port and copy it over that way?

Would you mind telling me what v.app is and how i would go about to convert it to that?
Click to expand...

Tape over USB? MAJOR no-no.
Tape drives, as I said, work in 256 kilobyte blocks. Compare this to your hard disk, which works in 512 byte blocks. That means 512 blocks on your hard drive equal one tape block. Now you've got to do that at 50MB/s or better for a couple hundred gigs. You've got SCSI though, so don't sweat it. SCSI is good. SCSI will get the job done. (It also tells me you're LTO3 or older. Hopefully.) SCSI also means you can connect it to anything with a SCSI card.

The problem we have is coming up with a proxy. You can't just copy from ESX to Solaris if you don't have someone there who knows Solaris. The proxy also is going to need a pretty healthy chunk of relatively fast disk for it.
You also can't use NotBackup - if you have to upgrade to 6.5, that's going to be at least $20,000 before the required agents at $3,500 per host before the additional "virtual terabyte" licensing rape. If they even figured out how to quote the damn thing yet. 6.0 is only good for file-level, so we might be able to do something there maybe, but unlikely. It's a complicated system, to put it mildly.

I'm gonna have to turn things over to Iopoetve here though, to figure out how to get the VMDKs off-host in a usable form first, though. There's absolutely no point in having a proxy of any sort. Is there some way to get snapshots off to a proxy in a usable format for an upgrade at all, Iopoetve?
 
so i shouldn't disconnect the scsi cable connecting the tape drive to the solaris box and connect it to the esx box instead(since esx wont recognize it)? Correct me if i'm wrong but what your trying to say is we can use the solaris box as a proxy if we can find someone that knows solaris, and if that happens we don't need to use netbackup.

Can I not create a VM on the ESX box and set up VCB proxy on it and use the VM as the proxy? I would imagine that the box would suffer some performance issues though.

Kinda off topic but can you clarify the differences between a SAN and a NAS and what a LUN is? I have a broad idea but would like to fully understand the difference.
 
syn3rgyz said:
so i shouldn't disconnect the scsi cable connecting the tape drive to the solaris box and connect it to the esx box instead(since esx wont recognize it)? Correct me if i'm wrong but what your trying to say is we can use the solaris box as a proxy if we can find someone that knows solaris, and if that happens we don't need to use netbackup.
Click to expand...

It's a rough summary, but reasonably accurate. Here's the thing; you need Server 2k3 or preferably 2k8. The thought I had was to basically setup an NFS share on the Solaris box, mount it on the proxy, dump to the NFS share. At that point, let NetBackup back itself up or use tar instead. (Which means manually loading tapes through the management interface and keeping notes.) Obviously, it requires you have someone who knows Solaris and 2k3/2k8 NFS.

Can I not create a VM on the ESX box and set up VCB proxy on it and use the VM as the proxy? I would imagine that the box would suffer some performance issues though.
Click to expand...

Have to defer to Iopoetve on that one. I was warned sternly by multiple people that it was NOT possible, because of the level of performance required as well as some restrictions on the proxy itself at the time.

Kinda off topic but can you clarify the differences between a SAN and a NAS and what a LUN is? I have a broad idea but would like to fully understand the difference.
Click to expand...

SAN is a Storage Area Network; FC is a SAN. InfiniBand can also be a SAN, depending on configuration.
NAS is Network Attached Storage; NFS, CIFS, and AFS are NAS methods. A NAS box is anything which provides storage over an existing Ethernet network.

A LUN is a "Logical Unit Number" in truth. Any Logical Unit Number can be any SCSI-type resource. (FC is actually SCSI internally.) So a tape drive will have a LUN, but so will a disk. Most folks just use LUN as shorthand for a logical disk on an array.
 
you can't go ESX -> solaris easily... scping the files isn't a really good idea, tbh.
You want a proxy of some kind to use VCB on if possible - that way they're compressed to avoid any maxfilesize issues, and so you can use converter to restore. If you have an adaptec card, you can hook the tape to the host, otherwise you can't. You could robocopy / rsync the files to the solaris box for tape though, if you wanted.
 
AreEss said:
It's a rough summary, but reasonably accurate. Here's the thing; you need Server 2k3 or preferably 2k8. The thought I had was to basically setup an NFS share on the Solaris box, mount it on the proxy, dump to the NFS share. At that point, let NetBackup back itself up or use tar instead. (Which means manually loading tapes through the management interface and keeping notes.) Obviously, it requires you have someone who knows Solaris and 2k3/2k8 NFS.
Click to expand...
Or that
Have to defer to Iopoetve on that one. I was warned sternly by multiple people that it was NOT possible, because of the level of performance required as well as some restrictions on the proxy itself at the time.
Click to expand...
It's possible now and supported, but not as much on 3.0.1. :( THat's the issue - most of the cool things don't work on that version, so it's not really useful :-/ You'd be doing "network" style backups on 3.0.1, which sucks
SAN is a Storage Area Network; FC is a SAN. InfiniBand can also be a SAN, depending on configuration.
NAS is Network Attached Storage; NFS, CIFS, and AFS are NAS methods. A NAS box is anything which provides storage over an existing Ethernet network.

A LUN is a "Logical Unit Number" in truth. Any Logical Unit Number can be any SCSI-type resource. (FC is actually SCSI internally.) So a tape drive will have a LUN, but so will a disk. Most folks just use LUN as shorthand for a logical disk on an array.
Click to expand...

To add - iSCSI is also a SAN instead of a NAS, as it does block level vs. file level access. :)
 
lopoetve said:
you can't go ESX -> solaris easily... scping the files isn't a really good idea, tbh.
Click to expand...

*smack* Hi. I'm the Solaris guy. For many, many years. Predating Solaris. Seriously. I know what the hell I'm doing, and then some. I've had to go down this road more than once before. There is absolutely no legitimate argument against transferring files between the two using any method. (Excepting Solaris 10's frequent bugs in the TCP/IP stack.)

The problem is that it's all moot, because he doesn't have a Solaris guy. Without an NFS share or NotBackup running right, it's not going to work. Without a good chunk of storage attached, it's really not going to work. And without somebody who knows tar well, or NotBackup, it's not going to work.

You want a proxy of some kind to use VCB on if possible - that way they're compressed to avoid any maxfilesize issues, and so you can use converter to restore. If you have an adaptec card, you can hook the tape to the host, otherwise you can't. You could robocopy / rsync the files to the solaris box for tape though, if you wanted.
Click to expand...

He's going to have to go to Solaris at this point. No money means no tape on Windows. There's absolutely no reasonable option. (He's almost certainly not licensed for NotBackup server on Windows. Hells, I don't know if he's properly licensed for the autoloader. I HATE NOTBACKUP LICENSING.)

The first question is still how we're going to get ANY backups out of ESX that'll work. We aren't going to be able to do jack shit until we can get a backup out of ESX and verify that it works for restore. Be that with VCB proxy or copying VMDKs, that's the most important piece of the puzzle.
The rest we need to toss aside till we get a solid solution for that, one that can be tested both backup and restore.
 
AreEss said:
*smack* Hi. I'm the Solaris guy. For many, many years. Predating Solaris. Seriously. I know what the hell I'm doing, and then some. I've had to go down this road more than once before. There is absolutely no legitimate argument against transferring files between the two using any method. (Excepting Solaris 10's frequent bugs in the TCP/IP stack.)

The problem is that it's all moot, because he doesn't have a Solaris guy. Without an NFS share or NotBackup running right, it's not going to work. Without a good chunk of storage attached, it's really not going to work. And without somebody who knows tar well, or NotBackup, it's not going to work.
Click to expand...
Yeah there is - ESX wasn't designed for it and the file types weren't designed to be housed on anything except VMFS. SCPing them back will copy them unaligned causing MAJOR performance hits. Even scping them to another VMFS volume will leave them unaligned - only the vmkernel can align them to the filesystem via a migration. There's also no integrity check in just scping them, while VCB does at least a little bit as it pulls things over. Limitation, ya. I'm a Solaris guy too - it's not the Solaris side, it's the design of ESX. That's why VCB exists. He'd also have to power the VMs all down since they're locked
He's going to have to go to Solaris at this point. No money means no tape on Windows. There's absolutely no reasonable option. (He's almost certainly not licensed for NotBackup server on Windows. Hells, I don't know if he's properly licensed for the autoloader. I HATE NOTBACKUP LICENSING.)

The first question is still how we're going to get ANY backups out of ESX that'll work. We aren't going to be able to do jack shit until we can get a backup out of ESX and verify that it works for restore. Be that with VCB proxy or copying VMDKs, that's the most important piece of the puzzle.
The rest we need to toss aside till we get a solid solution for that, one that can be tested both backup and restore.
Click to expand...

Granted, but it's going to have to go to windows somewhere first. Can't copy running VMs, and you don't want to scp them as you'll have issues later. We ~need~ to feed it through VCB.
 
lopoetve said:
Yeah there is - ESX wasn't designed for it and the file types weren't designed to be housed on anything except VMFS. SCPing them back will copy them unaligned causing MAJOR performance hits. Even scping them to another VMFS volume will leave them unaligned - only the vmkernel can align them to the filesystem via a migration. There's also no integrity check in just scping them, while VCB does at least a little bit as it pulls things over. Limitation, ya. I'm a Solaris guy too - it's not the Solaris side, it's the design of ESX. That's why VCB exists. He'd also have to power the VMs all down since they're locked.
Click to expand...

You have GOT to be kidding me.
If I wrote shit like that, I would get thrown out on my ass if I was lucky. That's just absolutely unreasonable on their part. Goddamn. And it's NOT hard to do that kind of a check in code, either. (If it was, then there wouldn't be any migration tool. It should NOT be that hard to convert it or expand it to an export-import tool.)
GODS. Excuse me while I go seethe at lazy bastards getting away with screwing over customers while I now have to try and figure out some sane way to work around their lack of effort and short-sightedness.

Granted, but it's going to have to go to windows somewhere first. Can't copy running VMs, and you don't want to scp them as you'll have issues later. We ~need~ to feed it through VCB.
Click to expand...

Except it's 3.0.x. VCB + 3.0.x == A VERY good reason to become an alcoholic in my experience.
If we had TSM, I'd frankly just say "screw it" and recommend taking guest level backups, nuking them, recreating from a golden image, and doing system restores at the guest level. I've never had problems with TSM doing that, and if I did, I'd have someone to call. But no, we've got NotBackup, so system level restores are flat out out of the question. If they seem to work, it just means Windows will blow up a few days later with registry corruption.
Talk about a problem making me rip my hair out. Because we really have to get the damn things onto Solaris somehow. Or SOMETHING with actual library management that'll talk SCSI+Ethernet. Yeah. Control path is IP. :mad:

Let's talk cutting out the tape for the moment. Rip it out of the picture. We do NOT have a tape drive, the end. It's gone. Thrown out. Exploded. Whatever.

VCB on 3.0.x, can we take that VCB "proxy" and just dump it as files to local disk or network disk? Not fancy shmancy stupid aligned garbage. No filesystem excuses. I want it to spit out standard frigging files. I don't care how it gets there, I only care that A) it's a standard damn file(s), and B) VCB will restore from saidsame files. If we can get that far, I think I can come up with something workable.
 
Check? What are they going to check? It takes moving the entire file again to align it. VMFS is a distributed locking new-era filesystem that is 100% totally proprietary. Just because there happens to be a linux VM that can mount it, doesn't mean that you can just move things around on it without using VMware's tools and expect it to just magically work! :p It expects that you're going to use the tools designed for it, NOT the tools designed for EXT3! They exist! Vmkfstools - give it a shot in the COS VM sometime. It's there for a reason :)

I do agree - VCB + 3.0.X is gonna be a whiskey and vodka event, but I don't think we have a choice. Poor Mans' vcb won't work for the same reason. I also agree that a guest level backup might be the easiest, as sad as it is.

VCB - it can dump it anywhere, pretty much, as long as the windows proxy can see it. It doesn't care if it's on a SAN, network share, or local disk - as long as it can keep up. Anything but another VMFS volume. And it spits out 2gb sparse normal files. :)

You dont' ever want to use VCB to restore. VCBrestore sucks more donkeyballs than a pre-4 firmware MSA. You use converter to restore :) And converter eats just about anything you want it too.
 
backing up images at guest level and restoring it to a golden image sounds plausible but very grueling.

If I am able to find someone who knows solaris, but not esx how would that work out?
 
syn3rgyz said:
i was just notified that we have the license for netbackup 6.5 if that helps
Click to expand...

Ok, question 2 - do you have licensing for the fully-integrated VMWare module? If not, that's ok - we can make that work too. If you do, fire it up!
 
fully integrated VMWare module??? Well i Just found out we have the license for VMWare VSphere and to upgrade to esx 4.0.
 
woot!

NB 6.5 and BE 12.5 and Commvault whatever.hellifIknow have built in modules that communicate straight with the hosts/VC. If not, you have to build a config.js file and use the pre-command.wsf and post-command.wsf files. :) If you have it, woot. If not, more-subdued-woot.
 
Yeah, but that's part of our problem here, Iopoetve.
NotBackup 6.5 licensing is an unholy nightmare. It's virtual terabytes plus features plus integration modules. The only "freebie" is their less than worthless BMR. That's also only getting us to 6.5; we need to be at 6.5.2a or better.
That also means we'll lose all functionality of any prior backups - they will NOT BE ABLE TO BE RESTORED. This is another known issue with 6.5.x that Symantec has as of yet not bothered to address. I cannot emphasize enough that NotBackup is EXTREMELY risky, proven to be dangerous, and should NOT be used for ANY mission critical needs EVER.

However, life gets easier. If we've got 2GB sparse files out of VCB, all we need to do is dump them to an NFS share on the Solaris box. From there? Screw it.
It's 2GB sparse files. We dump 'em with tar. NotBackup isn't worth the risk.
 
As long as it'll talk with VCB, that's all they need - it just does copies for VCB backups.
 
You must log in or register to reply here.
Back
Top