Non-official script! Provided on 'as-is' basis.

It is recommended to have vRangerPro DB backup before running the script!

Features:

1. Scans CIFS (only!) repository for existing Savepoints.

2. Generates new Global Manifest. Can be used to re-create missing Global Manifest.

3. Synchronizes DB records with actual repo content.

4. Can be executed from any PC with Powershell 2 installed.

5. Should work for non-USA customers. Tested on SpanishServer 2008 and Spanish SQL Express 2008.

Pros:

It fixes situation when imported SPs can not be deleted through GUI (Remove button disabled).

Re-scans/verifies existing repo. In theory some check procedure can be added, e.g. var is missing or unreasonably small var created.

Lets completely avoid ‘Restore from Manifest’.

Customer can create own set of SPs. For example, take following scenario. DR site. Repo exists, admin brings set of SPs from different locations and drops them into the repo share, runs script. Ranger displays both old (if still exist) and new SPs in restore grid. Regular restore job can be created from SP Grid.

Cons:

Requires version 2 of Powershell

Does not perform thorough check of backup content. Presence of 2 metadata files in SP directory is sufficient to consider SP existing.

SP directory should follow original naming convention: root_of_the_repo\<ObjectName>_<ObjectUUID>\<ObjectName>_<Date>_<Time>_<JobTemplate UUID>.

Instructions:

1. Launch Powershell, execute “Set-ExecutionPolicy Unrestricted” if necessary

2. run script

3. select SQL instance, provide credentials if necessary

4. select existing repo you would like to sync

5. provide credentials to access repo share if necessary

6. refresh Repo view in Ranger.

Old GlobalManifest and script log are saved in the root of the repository.

================ update. 03/09/2012 ==================

Some of you may have seen a following error when executing original version of a script.

Exception calling "ExecuteNonQuery" with "0" argument(s): "Conversion failed when converting from a character string to uniqueidentifier."

It happens due to a broken link between BackupTask and SavePoint tables. When backup task is completed successfully, the row in the BackupTask table should have a pointer to the corresponding savepoint. For some reason there are successful tasks with pointer set to NULL.

Attached new version (reposync02) of the script can handle this situation properly and will re-establish link between tables if necessary.

I also recommend to run following sql command to find if there are any broken links between 2 tables. Check 4th (Table_Link) column for NULL value.

This issue could be a reason for malfunctioning retention. SPs with broken link will most probably be ignored by retention mechanism.

SELECT t.TaskId, t.VmName, t.StartTime, bt.SavePointId AS Table_Link, sx.SavePointId

FROM Task t, BackupTask bt, SavePoint s, SavePointXml sx

WHERE t.TaskId = bt.TaskId

AND s.SavePointId = sx.SavePointId

AND bt.TaskId = sx.ManifestXml.value('/*[1]/JobTaskID[1]', 'uniqueidentifier')

AND s.IsDeleted = 0

ORDER BY t.StartTime

P.S. This script has been used in multiple support cases and proved to be very helpful. Especially taking into consideration some recent glitches with "FLR from Manifest".

The post is open for vote, questions and comments.

HI All,

I get error "Unable to match savepoint disk to existing VM disk" if I try to restore one VM from incremental BackUp.

It happens not by all VM's.

here is a LOG:

[2013-02-24 10:27:08.318]: vRanger Backup & Replication - v5.2.1.22438 | Target Host:esx-server, Repository:USB-Q1

[2013-02-24 10:27:08.318]: Task for virtual machine vm1 was queued.

[2013-02-24 10:27:08.568]: Beginning restore task for vm1

[2013-02-24 10:27:08.568]: Starting task validation.

[2013-02-24 10:27:30.645]: Ending task validation... success!

[2013-02-24 10:27:33.192]: Gathering data for esx-server from API completed.

[2013-02-24 10:27:33.208]: Retrieving Virtual Machine Configuration completed.

[2013-02-24 10:27:33.645]: Checking free space on DS SAN 01 datastore completed.

[2013-02-24 10:27:37.254]: Creating VM vm1 on host esx-server completed.

[2013-02-24 10:27:37.270]: Local machine is a physical machine.

[2013-02-24 10:27:37.286]: Restore task will attempt using VDDK SAN.

[2013-02-24 10:27:39.551]: Creating a snapshot for vRanger completed.

[2013-02-24 10:27:39.551]: Restore task using VDDK SAN failed: Unable to match savepoint disk to existing VM disk

[2013-02-24 10:27:39.551]: Restore task failed: Unable to match savepoint disk to existing VM disk

did somebody face this issue?

After downgrading upgrading from vSphere ESX4.1u2 to ESXi 5.0 we get a performance problems and snapshot problems all over the place.

A lot of VM now needs now some more time for creating a snapshot and vRanger Pro only waits up to 5min and than mark the backup task as failed. If the snapshot creation finishing a short time later this ends in an unwanted Snap which isnt automaticly deleted. Similar problem we have with a few custom quiescing scripts which needs more than 5min do to their job.

We are also ineffected that on a few VMs always two snapshots are created at the same time which ends up that vRanger cant use CBT when performing a LAN-FREE Backup. This problems also exists when performing a snap with quiescing in the vSphere Client. Looks like a VMware problem and a case was opened. But i already hear about this problem from a Quest SE earlier this year.

So.... how can i increase the timeout period for the vranger service?

For all who downgrading upgrading from vSphere 4 to 5 it would be wise to just to upgrade your smallest cluster first or just a few hosts and see what your vRanger 5.3 says. This environment has backuped 120 VMs every day with a success rate of >99%. After upgrading 2/3 of the (13)Hosts the rate drops down to 70% at a first try and the backup window isnt long enough anymore. Largest job of 65 VMs finished in 499min when use the old COS and with LAN-FREE we are down to 926min with 14 failures (after tweaking).

Problems we seen:

- VA Appliance cant be shutdown over vsphere Client (VMware Tools are installed)

- Double Snapsthots

- Snapshots leave behind

- Timeout problems, Failed to create vRanger snapshot, API Call Failure,  Error Message: Die zugrunde liegende Verbindung wurde geschlossen: Eine Verbindung, deren Aufrechterhaltung erwartet wurde, ist vom Server geschlossen worden.. , Error Message: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt., Error Message: Unable to continue Differential backup; the vRanger snapshot was not found. Error Message: RETRY timedout operation timed out [at xtimedwait:416], Error Message: Der Index lag außerhalb des Bereichs. Er muss nicht negativ und kleiner als die Auflistung sein.Parametername: index

- Duration period of running jobs are resetet when performing some work in vRanger (i deleted a batch of non-working Replication jobs). The task now shows a higher runtime than the job.

- Transport mode is not editable (modify is greyed out) so old replication jobs have to recreate

- LAN Mode is "slow" compared to COS and our Server, which use a older Quad Core XEON, is now CPU bound when reaching ~70MB/s incomming traffic and runing up to 10 task in parallel.

- The Name "VA-HotAdd" is not the right term because the work is not performing by the VAs and you have to install the vRanger in a single VM. So scaling looks limited to a single installation and depending of the enviroment the Backup is on wrong site when having a two production site. Otherwise you have to  presenting all LUNs to the Host which holds the vRanger VM.

Regards

Joerg

Hello,

I've readed install guide and there is nothing about vSphere 5.1, does it support this version or not?

Thanks in advance.

Hi all,

I copied catalog backup from one site to another site.

I create a new repository from the directory imported but I'm not be able to see catalog from this repository....any ideas ?

thanks in advance

Andre

We've been having trouble with vRanger since version 3 as some of the backup jobs would fail. Fortunately that only happened once or twice a month so it wasn't a big problem. But after upgrading from 5 to version 6 the failed jobs are way more frequent - every day or every second day. Every day it's a different machine, but it's almost always this error message ("The operation has timed out" or "Unable to locate host esx1.local").

Now the actual question is if anyone knows if there is a config setting in the vRanger xml file that would increase this timeout?

Hi,

I have a problem with vRanger on a Server 2003 SP2.

VMWare v5 and the snapshot is successful created.

The job is starting as expected but the throughput is always N/A and nothing happens.

any idea?

regards

Maximilian

Hi all,

I’ve recently started looking after a vRanger server which is in US. All the machines in there are getting backed up as normal however onthree machines I get same message and they fail every time.

Message is “Backup failed: An internal error occurredduring execution, please contact Vizioncore support if the error persists.  Error Message: 2654 -  can't read phys:/vmfs/volumes/49a88c4e-d71a666c-2155-00237d22803a/hostname/hostname-000001-flat.vmdk[at io_size:125]”

I’ve rebooted the server and that did not help.

I found two links but I am confused which one is correct .......

http://www.lo0.ro/2011/vranger-5-cant-read-phys-vmfs-volumes/

http://quest-software.uat3.hosted.jivesoftware.com/thread/1927

Hostname changes in the error message forother machines. Here we are running vRanger backup and replication 5.0.0.19238.

Any suggestions on why this is failing?

Thank you in advance

Hi everybody,

I've got one question with no answer from Quest Software...

Here is my configuration :

2 x ESXi 5 with VMware Essential Plus Acceleration Kit

1 x physical vRanger Server 5.2 with vCenter 5 Server.

San configuration : my physical vRanger can see all VMware Datastore Luns in windows disk manager (diskpart with automount disable and automount scrub).

vRanger configuration : VDDK SAN transport for lan free backup and lan backup if lanfree failed.

My problem :

I can't backup my VMs with LAN-free :

Lan Backup is ok.

My vRanger Server is not a VM so i don't need the hot-add function.

Authentication is ok to vCenter Server and ESXi host (with root account).

Does anyone have an idea ??

Thanks,

Regards.

Hey guys.

I have a problem with the logs from Exchange 2010 VM after a Backupjob. Normaly the vRanger delete the logs automatically after the job is finished.

But since a few weeks the logs are not deleted. Have anyone an idea what will be happen or what is wrong??

Versions:

Exchange --> 2010 on 2008R2 Standard

vRanger --> 5.2.1

vSphere --> ESXi 4.1 Update 2

Thanks for help in advanced!

Greets, Matthias

Good day,

We somewhat recently upgraded from vRanger 3.1 to 5.3, and we are really pleased with the new version. One funny thing though is that we are seeing a snapshot time out error, probably due to pre-freeze-script. The pre-freeze-script runs a job that takes close to 10 minutes to complete. Naturally, vRanger must wait for the script to run its course before taking the snapshot, which is what vRanger does in 3.1. However, vRanger 5.3 doesn't seem to want to wait that long for the script to finish. It appears that vRanger is throwing a timout error and quitting the back up well before the script finishes running. The script completes successfully with a return code of 0 by the way.

So I guess what I want to know is:

1) Is there a pre-freeze-script time out mechanism in 5.3 that was lacking in 3.1?

2) If so, is there a way to manually change the time out value to something larger?

Thank you for your help.

I did a full backup of a test VM the other night and it worked great and I was able to restore it. I tried one of our production servers next and I got the below email when it failed. I'm not sure if there is any other information somewhere withing vRanger to look at but this is all I have now. Would anyone know a cause of why this one didn't work?

Thanks.

Host Name: VEEAM
Job Name: Backup 'WINAT'
Inventory Name: WINAT
Result: Completed
Start Time: 1/30/2013 6:30:51 PM
End Time: 1/30/2013 6:30:58 PM
Duration: 1 minute(s)
Backup Type: Full


Machine Name: WINAT
Result: Failed
Start Time: 1/30/2013 6:30:54 PM
End Time: 1/30/2013 6:30:58 PM
Duration (minutes): 0
Archive Size: 0 GB
Message: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: Object reference not set to an instance of an object.

We are regulalry seeing this failure message and once it hits then all following backups fail (obviously). I'm guessing it's associated with the metadata.exe processes being stuck as I can guarantee I will see many of these whenever we see the failure message.

I'm at the point now where I have to reboot every other night to ensure success, which is crazy I'm sure you will agree. Does anyone have any idea when this will ever be resolved. This has got worse since upgrading to 5.5.

Thanks for any suggestions or pointers.

Hi,

This will be my first post since i used the products for the past few years.

I got a problem with HotAdd at the moment, which doesn't seem to work correctly.

From the 45 virtual machines we backup daily, mostly only 5 random work thru HotAdd, the rest is thru LAN

Since there is support for ESXi and vCenter 5.1 we made the jump from 5.3.2 to version 6.0.1

We also upgraded our hosts from 4.1 to 5.1, our vCenter was already 5.1 for awhile now...

And we changed from a virtual to a physical vRanger server on top of Windows 2008 R2 which is fully patched with 5 VA's (one per host)

Everything works ok ... even cataloging works now (which never worked for us in 5.x)

Here is a log file of one if the failures:

[2013-02-12 20:01:06.246]: vRanger Backup & Replication - v6.0.1.31606
[2013-02-12 20:01:06.246]: Selected Options: Compress backed up files. | Enable guest quiescing. | Enable Active Block Mapping (ABM). | Enable Cataloging. | Selected SpaceSavingTech: Incremental | Included Disks [1].
[2013-02-12 20:01:06.246]: Task for virtual machine ap-xxx01-sql was queued.
[2013-02-12 20:23:00.381]: SourceVm:ap-xxx01-sql | Uuid:xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx | VC:ap-xxx00-vc.xxx.lan, Host:vm-xxx03.xxx.lan [ESXi 5.1.0]
[2013-02-12 20:23:00.381]: Beginning backup task for ap-xxx01-sql
[2013-02-12 20:23:00.381]: Starting task validation.
[2013-02-12 20:23:00.381]: Connection to vm-xxx03.xxx.lan was properly validated.
[2013-02-12 20:23:00.381]: vm-xxx03.xxx.lan is properly licensed.
[2013-02-12 20:23:00.397]: Test connection to repository Database Servers starting...
[2013-02-12 20:23:00.974]: Test connection to repository Database Servers successful!
[2013-02-12 20:23:01.473]: Ending task validation... success!
[2013-02-12 20:23:01.473]: Beginning initialization of backup information.
[2013-02-12 20:23:01.473]: Retrieving the tasks parent information.
[2013-02-12 20:23:07.074]: Retrieving save points for any full backups associated with this job.
[2013-02-12 20:23:07.167]: Verifying content of repository.
[2013-02-12 20:23:09.180]: Finished initialization of backup information successfully.
[2013-02-12 20:23:09.180]: An Incremental backup will be run for this task.
[2013-02-12 20:23:09.289]: Gathering credentials for ap-xxx01-sql completed.
[2013-02-12 20:23:09.554]: Checking for VMotion completed.
[2013-02-12 20:23:10.911]: Gathering data for ap-xxx01-sql from API completed.
[2013-02-12 20:23:12.050]: Gathering data for vm-xxx03.xxx.lan from API completed.
[2013-02-12 20:23:15.154]: Retrieving the VM BIOS configuration completed.
[2013-02-12 20:23:16.215]: Gathering credentials for va-xxx03-vranger completed.
[2013-02-12 20:23:17.260]: Gathering data for va-xxx03-vranger from API completed.
[2013-02-12 20:23:18.040]: Validating connectivity to virtual appliance 10.9.2.3 completed.
[2013-02-12 20:30:25.369]: Creating a quiesce snapshot for vRanger completed.
[2013-02-12 20:30:32.732]: Gathering data for ap-xxx01-sql from API completed.
[2013-02-12 20:30:32.747]: Local machine is a physical machine.
[2013-02-12 20:30:32.747]: Backup task will attempt to use VA-based VDDK HotAdd.
[2013-02-12 20:30:57.286]: Using filter type(s) change block and active map for disk: vix:r:ap-xxx00-vc.xxx.lan:902:[na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:33:28.683]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: 3201 - can't open [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:33:28.699]: The failed backup task will be retried.
[2013-02-12 20:36:03.387]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: 3201 - can't open [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:36:03.387]: The failed backup task will be retried.
[2013-02-12 20:38:49.635]: Backup task using VA-based VDDK HotAdd failed: An internal error occurred during execution, please contact Quest support if the error persists.  Error Message: 3201 - can't open [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:38:49.651]: Check the manual for compatibility issues when attempting Lan-free operations.
[2013-02-12 20:38:49.651]: Backup task will be attempted using a VA-based VDDK network connection.
[2013-02-12 20:38:49.651]: Windows Server 2008 OS detected, application-level quiescing is Disabled during the VDDK backup.
[2013-02-12 20:39:14.954]: Using filter type(s) change block and active map for disk: vix:r:ap-xxx00-vc.xxx.lan:902:[na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:39:24.251]: Beginning Cataloging of [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk
[2013-02-12 20:39:55.108]: Catalog data for [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk volume 1 was queued to save successfully.
[2013-02-12 20:39:55.124]: Catalog data for [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk volume 2 was queued to save successfully.
[2013-02-12 20:39:55.124]: Disk [na-xxx01-data2] ap-xxx01-sql/ap-xxx01-sql_1.vmdk is skipped per backup. Cataloging of disk is skipped.
[2013-02-12 20:40:14.218]: Backing up disk 'vix:r:ap-xxx00-vc.xxx.lan:902:[na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk:moref=vm-375330:snapshot-519895:6' completed.
[2013-02-12 20:40:14.234]: Checking and enforcing retention policy completed.
[2013-02-12 20:40:38.195]: Removing snapshot for vRanger completed.
[2013-02-12 20:40:38.819]: Commiting savepoint data to Database Servers completed.
[2013-02-12 20:40:40.597]: Verifying the content of the repository completed.
[2013-02-12 20:40:41.081]: Setting VM event completed.
[2013-02-12 20:40:41.377]: Catalog data for disk [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk volume 1 has been queued to activate.
[2013-02-12 20:40:41.393]: Catalog data for disk [na-xxx01-nfs] ap-xxx01-sql/ap-xxx01-sql.vmdk volume 2 has been queued to activate.

Hey guys.

I have a problem with the logs from Exchange 2010 VM after a Backupjob. Normaly the vRanger delete the logs automatically after the job is finished.

But since a few weeks the logs are not deleted. Have anyone an idea what will be happen or what is wrong??

Versions:

Exchange --> 2010 on 2008R2 Standard

vRanger --> 5.2.1

vSphere --> ESXi 4.1 Update 2

Thanks for help in advanced!

Greets, Matthias

We've been having trouble with vRanger since version 3 as some of the backup jobs would fail. Fortunately that only happened once or twice a month so it wasn't a big problem. But after upgrading from 5 to version 6 the failed jobs are way more frequent - every day or every second day. Every day it's a different machine, but it's almost always this error message ("The operation has timed out" or "Unable to locate host esx1.local").

Now the actual question is if anyone knows if there is a config setting in the vRanger xml file that would increase this timeout?

I did a full backup of a test VM the other night and it worked great and I was able to restore it. I tried one of our production servers next and I got the below email when it failed. I'm not sure if there is any other information somewhere withing vRanger to look at but this is all I have now. Would anyone know a cause of why this one didn't work?

Thanks.

Host Name: VEEAM
Job Name: Backup 'WINAT'
Inventory Name: WINAT
Result: Completed
Start Time: 1/30/2013 6:30:51 PM
End Time: 1/30/2013 6:30:58 PM
Duration: 1 minute(s)
Backup Type: Full


Machine Name: WINAT
Result: Failed
Start Time: 1/30/2013 6:30:54 PM
End Time: 1/30/2013 6:30:58 PM
Duration (minutes): 0
Archive Size: 0 GB
Message: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: Object reference not set to an instance of an object.