Error unable to backup due to error in vmdk backup

I recently began seeing this error on a system that had long been running flawlessly, and which had not been changed. One difference is that ghettoVCB was successfully backing up the other VMs on the system.

Direct execution of vmkfstools clone command resulted in the same error, with 3 different target file systems. The VM was powered down for this attempt.

This is a windows 7 pro VM. What ultimately worked for me was the following:

• defrag the drive (used defraggler)
• zero the free space (sdeletesdelete -z c:)
• chkdsk c: /f
• reboot
• shutdown
• ssh to esxi 5.5 box
• vmkfstools -i /path/to/disk.vmdk -d thin /path/to/disk_backup.vmdk
  • note the «-d thin» is useless when writing to the same physical medium as the source disk.

SUCCESS!

• vmkfstools -E /path/to/disk.vmdk /path/to/renamed_disk.vmdk
• vmkfstools -E /path/to/disk_backup.vmdk /path/to/disk.vmdk
• Start up the vm to test
• run ghettoVCB against the VM while the VM was «powered up» (with the added benefit that the «thin» parameter applies when writing from the source to the NFS target).

SUCCESS!

I suspect the sdelete command was the key operation.

Remember to remove the renamed_disk.vmdk and renamed_disk-flat.vmdk

addenda (2020-11-03)

This issue recently came up in the ghettoVCB mailing list (Error in VMDK backup (#202)). This is the thread for ghettoVCB on GitHub.

the user described this issue, then later posted this fix:

So I made one change, and that was to mount my backup datastore as
nfs3 instead of nfs4. This seems t have solved the issue. Not sure why
it is, but posting this in case anyone else runs into a similar issue.

There was also a handy tip for troubleshooting in the thread, contributed by another user:

Some times is difficult to find an error on vmkfstools phase, like a
bad block on a storage, the returned error is a generic error.

Using -v 10 on vmkfstools line, like above, you can watch and find the
error, but when ghettoVCB.sh runs on CRON schedule, the captured log
does not includes the debug lines from vmkfstools:

Lines changed:

if [[ -z «${FORMAT_OPTION}» ]] ; then
logger «debug» > «${VMKFSTOOLS_CMD} -i «${SOURCE_VMDK}» -a «${ADAPTER_FORMAT}» «${DESTINATIO …
${VMKFSTOOLS_CMD} -v 10 -i «${SOURCE_VMDK}» -a «${ADAPTER_FORMAT}» «${DESTINATION_VMDK}» > «${V…
else
logger «debug» «${VMKFSTOOLS_CMD} -i «${SOURCE_VMDK}» -a «${ADAPTER_FORMAT}» -d «${FORMAT_…
${VMKFSTOOLS_CMD} -v 10 -i «${SOURCE_VMDK}» -a «${ADAPTER_FORMAT}» -d «${FORMAT_OPTION}» «${DES
fi

where «lines changed» are in the ghettoVCB.sh script.

ghettoVCB: ERROR: Unable to backup MACHINE-NAME due to error in VMDK backup

I’m on VMware ESXI 5.0.0 Update 1 and wanted to use the ghettoVCB script for backuping my VMs.

The dryrun went perfectly fine:

But when I try to do an actual backup, I get the following message for every VM on my host:

What am I doing wrong? As I didn’t want to paste every configuration snippet from my configuration, please ask if you need more specific information.

The backup is supposed to be saved to a NFS share which is correctly mounted on my ESXi host.

Thanks for your help :-).

2 Answers 2

the most I can suggest by seeing the output is:

1) Are you sure the path to your NFS mount or datastore is correct in the ghettoVCB configs? Double check all NFS configs for ghettoVCB.

2) Is your NFS share accepting anonymous access and granting read/write permissions?

Judging by the output, the script was able to create the snapshot but then 5 seconds later it said it could not back up the VMDK. My guess is this is a permissions issue on NFS mount. That, or lack of free space.

I recently began seeing this error on a system that had long been running flawlessly, and which had not been changed. One difference is that ghettoVCB was successfully backing up the other VMs on the system.

Direct execution of vmkfstools clone command resulted in the same error, with 3 different target file systems. The VM was powered down for this attempt.

This is a windows 7 pro VM. What ultimately worked for me was the following:

• defrag the drive (used defraggler)
• zero the free space (sdeletesdelete -z c:)
• chkdsk c: /f
• reboot
• shutdown
• ssh to esxi 5.5 box
• vmkfstools -i /path/to/disk.vmdk -d thin /path/to/disk_backup.vmdk
  • note the «-d thin» is useless when writing to the same physical medium as the source disk.

• vmkfstools -E /path/to/disk.vmdk /path/to/renamed_disk.vmdk
• vmkfstools -E /path/to/disk_backup.vmdk /path/to/disk.vmdk
• Start up the vm to test
• run ghettoVCB against the VM while the VM was «powered up» (with the added benefit that the «thin» parameter applies when writing from the source to the NFS target).

I suspect the sdelete command was the key operation.

Remember to remove the renamed_disk.vmdk and renamed_disk-flat.vmdk

This issue recently came up in the ghettoVCB mailing list (Error in VMDK backup (#202)). This is the thread for ghettoVCB on GitHub.

the user described this issue, then later posted this fix:

So I made one change, and that was to mount my backup datastore as nfs3 instead of nfs4. This seems t have solved the issue. Not sure why it is, but posting this in case anyone else runs into a similar issue.

There was also a handy tip for troubleshooting in the thread, contributed by another user:

Some times is difficult to find an error on vmkfstools phase, like a bad block on a storage, the returned error is a generic error.

Источник

Unable to backup due to error in vmdk backup

We have a ESXi 4.1 hypervirsor running a single VM about 400GB of size. We are backing up this VM to a Cisco NSS322 iSCSI device.

Performance is quite good about 100MB/s

The problem is that if I run manualy the backup job ./ghettoVCB -f vm_list1 -d debug, the backup job runs smoothly without errors.

But when started form a cronjob it will randomly quit spitting out an error .

I have run both ways with debug switch on but I cannot pinpoint the problem.

There is another host backing up to the same iSCSI datastore and I’m sure that the backup jobs do not run at the same time, not that it sould matter.

2011-11-08 23:00:02 — info: Initiate backup for dc01.xxxxxxxxx.local

2011-11-08 23:00:02 — info: Creating Snapshot «ghettoVCB-snapshot-2011-11-08» for dc01.xxxxxxxxx.local

2011-11-08 23:01:08 — debug: Waiting for snapshot «ghettoVCB-snapshot-2011-11-08» to be created

2011-11-08 23:01:08 — debug: Snapshot timeout set to: 900 seconds

2011-11-08 23:01:08 — debug: /sbin/vmkfstools -i «/vmfs/volumes/datastore1/dc01.xxxxxxxxx.local/dc01.xxxxxxxxx.local_1.vmdk» -a «buslogic» -d «thin» «/vmfs/volumes/4df9a8e7-29071038-6389-68b599aed801/vmbackup//dc01.xxxxxxxxx.local/dc01.xxxxxxxxx.local-2011-11-08_23-00-01/dc01.talokeskuskotka.local_1.vmdk»

2011-11-08 23:43:01 — info: ERROR: error in backing up of «/vmfs/volumes/datastore1/dc01.xxxxxxxxx.local/dc01.xxxxxxxxx.local_1.vmdk» for dc01.xxxxxxxxx.local

2011-11-08 23:43:01 — debug: /sbin/vmkfstools -i «/vmfs/volumes/datastore1/dc01.xxxxxxxxx.local/dc01.xxxxxxxxx.local.vmdk» -a «buslogic» -d «thin» «/vmfs/volumes/4df9a8e7-29071038-6389-68b599aed801/vmbackup//dc01.xxxxxxxxx.local/dc01.xxxxxxxxx.local-2011-11-08_23-00-01/dc01.xxxxxxxxx.local.vmdk»

2011-11-09 00:24:56 — info: ERROR: error in backing up of «/vmfs/volumes/datastore1/dc01.xxxxxxxxx.local/dc01.xxxxxxxxx.local.vmdk» for dc01.xxxxxxxxx.local

2011-11-09 00:25:04 — info: Removing snapshot from dc01.xxxxxxxxx.local .

2011-11-09 00:25:05 — info: Backup Duration: 85.05 Minutes

2011-11-09 00:25:05 — info: ERROR: Unable to backup dc01.xxxxxxxxx.local due to error in VMDK backup!

What sould I do next to find out where exactly the problem is.

The cronjob commandline is EXACTLY the same that I run manualy from the shell.

Источник

Independent disk error #18

I recive errors when backing up VM having some independent disks, ie:

2013-03-21 07:54:55 — info: WARN: VirualMachineToBeBackedUp has some Independent VMDKs that can not be backed up!

2013-03-21 07:54:58 — info: ###### Final status: ERROR: No VMs backed up! ######

The fact that independent disks are not backed up is fine — that’s why i’ve made them indepentend.
What is more, despite error, backups seem to be OK (have not tryed restore yet, but disks that are supposed to be backed up have legit sizes). In previous versions of ghettoVCB there was warning, not an error (especially saying that no VM’s have been backed up) . Could you please have a look at the issue?

Thanks in advance!

The text was updated successfully, but these errors were encountered:

I just tested this scenario and I get the following when I have a VM with independent disk:

Final status: WARNING: All VMs backed up, but some disk(s) failed!

Can you provide a bit more details on the VM? Does it only have independent disks or does it contain regular disks? Are you trying to backup a single VM or are there others?

This is weird,
I’ve just (after these 3 days since i’ve posted this issue) re-checked log files of scheduled backups — one definition contains 3 VM’s, one of which has independent disk. Log file shows WARNING (the exact one you’ve posted), not an ERROR.
No idea where it came from earlier (output posted in the first post was copy-pasted and the error did happen, really).

Seems like I’ve wasted some of your time — really sorry for that.
However I’ll keep an eye on this and get back in touch if it re-occurs.

Big thanks for concern and once again sorry for the «false-positive».

No worries. Glad it’s working for you

Hi,
I’m expecting the same problem, installed 2 days ago downloading from zip package.

the report email has error statement in object:
ghettoVCB — esx2 ###### Final status: ERROR: No VMs backed up! ######

and both, WARN adn ERR in body:
013-04-05 10:07:16 — info: Backup Duration: 1.82 Minutes
2013-04-05 10:07:16 — info: WARN: Formica has some Independent VMDKs that can not be backed up!

2013-04-05 10:07:22 — info: ###### Final status: ERROR: No VMs backed up! ######

do you have suggestions ?

i’m trying to debug this by myself:

first thing i found is the getFinalStatus function, i exit on the last IF statement :
[[ $VM_OK == 0 ]]
with status: ###### Final status: ERROR: No VMs backed up! ######»

while i am expecting to exit from the 3rd IF statement:

[[ $VM_OK == 1 ]] && [[ $VM_FAILED == 0 ]] && [[ $VMDK_FAILED == 1 ]]
with status: ###### Final status: WARNING: All VMs backed up, but some disk(s) failed! ######

and the output is:
2013-04-05 13:42:13 — info: debug getFinalStatus last ELIF: vm_ok 0
2013-04-05 13:42:13 — info: debug getFinalStatus last ELIF: vm_failed 0
2013-04-05 13:42:13 — info: debug getFinalStatus last ELIF: vmdk_failed 1

0 0 1 while i need a 1 0 1 to exit with the correct status.
now i’m going to check where the VM_OK is going to be setted as 1,
maybe this is happening only after a FULL success of at least one virtual machine, success that i never meet because i’m using the script with the «-m vmName» param. to backup a single vm.

i’ll post again after some tests.

ok, it seems to me (IMHO) that the problem is exactly this one: at least one VM have to complete a successful backup without having indipendent disk WARNs or something else.

So if all your VMs will fall into one of this conditions:

VM_OK value will be never set to 1 because this will happend after the ELSE.

this could be fine for the first 2 conditions because they are errors preventing the backup to be done, but the 3rd one is just a warning so it should be moved after the ELSE letting the VM_OK take the 1 value because i do have a working backup of at least one VM.

just my 2 cents . let me know if i’m wrong.

Marco.
sorry for my poor english.

i’ve moved the IF VM_HAS_INDEPENDENT_DISKS after the ELSE and it works now.
please report me if i’ve missed some side effects requiring that condition to be on its original place

i’ve also deleted the «create simlink for rsync» section inside that IF as it will be already executed (already written) just after the ELSE.

Источник

Veeam R&D Forums

Technical discussions about Veeam products and related data center technologies

Backup solution for branch offices

Backup solution for branch offices

Post by crichardson » Sep 02, 2014 2:24 pm this post

We have Veeam B&R running at our Head Office backing up our entire virtual infrastructure as well as replicating to our DR site. It works great.

However we have 30 branch office locations with slow connections. The average branch connection is only 3mbps. Each branch has a single ESXi server with a single virtual machine. The virtual machine is used for printing services and local shared network drives.

Since backing up over the WAN is impossible, I currently I have cheap NAS devices in each branch location. The NAS device is added to the ESXi host as an NFS datastore. I use ghettoVCB to backup the virtual machine to the NAS device every weekend.

This has become a massive headache. For one, the cheap NAS devices are failing. I’m slowly replacing them with Buffalo NAS devices which seem to be much better. But the ghettoVCB script constantly fails with the error «Unable to backup VM due to error in VMDK backup!». The real issue is the stability of the script itself. It’s not an ideal solution for backing up my branch servers.

I was hoping there was a way to leverage Veeam to backup my branch server’s virtual machines to their local NAS devices. Can I turn my branch server VM’s into proxies which backup themselves to network storage such as the NAS or NFS datastore?

Re: Backup solution for branch offices

Post by nielsengelen » Sep 02, 2014 3:27 pm 1 person likes this post

You can configure the branch office Windows servers as a proxy and use them to backup to the NAS share via CIFS/NFS.

You will have to add those backup targets to the Veeam server in the central place as well as those proxy servers. Furthermore you’ll have to license all the ESXi hosts in the remote branches with Veeam.

Do keep in mind that you’ll need to have a secure connection between the branches (ideally something like a VPN) because you’ll have to open up ports to create the connection.

Another option is to deploy an extra VM in all the additional branches and install Veeam Backup & Replication on those servers for local backups.

You can then add these remote Veeam Backup & Replication servers to the central Veeam server using the Enterprise Manager so you can easily manage them.

Источник

Script deletes old backup due to rotation count even if an error has occured on the next. #107

If one of the vdmk fails for some reason (ie. disk space) it simply deletes it then carries on to the next vmdk in that machine — probably better to give up here instead of wasting time with an inconsistent backup?

Once that is done, it finishes with «info: ERROR: Unable to backup . due to error in VMDK backup» but then goes and clears the previous backup due to having VM_BACKUP_ROTATION_COUNT set to 1.

This leaves the «newest» backup existing missing some VDMK files.

On failure would it be better to simply delete the current working folder?

The text was updated successfully, but these errors were encountered:

Totally agree on this, I had the same scenario where an incomplete backup deleted my only previous OK backup and I just realised (of course) when I needed it. I think that changing the behaviour to delete the «problematic» backup rather than the old one is much better. The only drawback being that this leads to a final state whereas the actual behaviour leads to a right backup every two cycles in the scenario of not enough free space for two full backups at the same time.
What I mean is:
(scenario: free space 1 TB, backup needs 600GB.)
-first backup: everything right. 600 GB Backup, 400 GB free.
-second backup fails on account of not having 600 GB free. you end up with an incomplete backup and more than 600 GB free

• third backup works ok. 600 GB Backup, 400 GB free.
  and so on.

Whereas with the proposed methodology:
(scenario: free space 1 TB, backup needs 600GB.)
-first backup: everything right. 600 GB Backup, 400 GB free.
-second backup fails on account of not having 600 GB free. you end up with the old OK backup and 400 GB free
and so on.

Anyway I think it’s still better than not having a valid backup for half the time.
Let me know if I can be of any help.

Your last section is what I meant, and sure you don’t get new backups, but an old backup is better than a broken one.

Either way it should be monitored, as it is there is nothing you can do even if you check it daily and it deletes a good backup.

I think to be safe everyone should assume they have space for at least 2 more backups than they intend to keep.

Being able to backup to a temporary area before deleting one and then moving it would be a good idea.

The request linked above I have been using since I posted it without problems.

Источник

10 Replies