And this time, it's a question. To recap what we're doing is I've a SATA drive in a USB enclosure plugged into out Dell 6800 which of course is running ESX 3.0. What we're trying to do is use this SATA drive as a backup device for our VMs. Since purchasing ESXRanger or even esXpress is out of the question (some monetary reasons, but mostly the network would be rather swamped), I'm stuck having to do it at the command line.
I found a procedure for backing up the VMDKs from a VMFS disk to a non-VMFS disk. I'm using vmkfstools -i /path of system to backup/system.vmdk -d 2gbsparse /path where it's backed up to/system.vmdk. The cloning procedure works fine, and out of a 4 GB test system, I get 5 vmdk files, one named test.vmdk, and the other four named test-s001.vmdk thru test-s004.vmdk.
So far, so good.
Now, the problem I'm running into, in trying to restore them (I'm going from a non-VMFS to a VMFS disk now). Thanks to bertdb and oreeh for responding to my non points question. They gave me a procedure that goes:
vmkfstools -i /restore from where I backed it up/system.vmdk /system I want to restore/system.vmdk.
When I run this procedure, no matter which of the five hard disks I try it on, it says they aren't virtual disks at all. The man file is of very little help, so anyone who can assist, I would greatly appreciate.
The entire idea of this exercise is to keep everything local rather than go over the network. I've used VM Convertor, and a whole host of other apps to move VMs around, and to even store them on my workstation Hard Drive. Trouble is, anytime I do that, it bring the network to a crawl. Night times aren't any good, as we have backups that will time out and fail if we run at night (tried it), and weekends are just as bad. That's why I want to try to keep the backup local.
the 5 files you copied out to the backup device, are they all in the same directory on the USD device? if so you should just be running:
"vmkfstools -i /path-to-USB-device/test.vmdk /vmfs/volumes/(path where files is to be)/test.vmdk"
you don't need to run it against the *.vmdk-001 -004 files as the script will recompile the disk for you.
Tried that as well. It insisist that the the test.vmdk (as well as all the others) aren't disk files. I'm half thinking that somehow, someway, they're getting corrupted, and that's my headache.
SOLUTION: Hi everyone,
After beating my head against the wall, and so and so forth, and boring everyone to tears, I got a solution. In the course of talking my problem over with a user group I belonged to, somone made the suggestion that I try plugging the USB drive into one of the other three USB ports. That led me to thinking a bit that maybe it wasn't so much the port, and it was the drive, and or enclosurer. This AM, I took a small 40 GB external drive we use for laptops, plugged it in, set it up, ran vmkfstools -i /location I wanted backed up/machine vmdk -d 2gbsparse /location of file/machine.vmdk, and then restored that vmdk to another directory back on the VMFS drive.
I thn plugged in the system I'd be trying to use (the hard drive was housed in a Bytecc case, I not sure about the model number and etc), reset up everything, and got the exact same problem I'd experienced before.
I then took the hard drive out of that case, at trasnferred it over to a Bytecc BT-380 enclosurer. Plugged it all in, reset up the drive, and etc, and this time the restore went off with out a hitch.
Bottom line, when it doesn't make sense and it's working for everyone else, look at your hardware.