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.

================ update. 05/28/2013 ==================

New version of the script has been posted:
http://communities.quest.com/thread/23459?tstart=0

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.

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

This is a new version of the popular reposync script. (http://communities.quest.com/thread/10839?tstart=0)

Thanks to collaboration with R&D the script works with all repo types. Based on support experience, few extra features have been included.

Features:

1. Supports all repo types.
2. Depending on immediate goal, synchronizes either whole repo or set of directories.
3. Thoroughly validates each SP. Practically what Ranger does while importing.
4. Imports both VM and physical server SPs.
5. Displays SP being processed at the moment, number of found SPs and processing time for each SP.
6. Revives retention if an original template (and corresponding job/task) that created imported SPs still exists.
7. Expires old SPs with given threshold date. Integrity of Incr/Diff set is preserved.
8. Creates/updates a GlobalManifest (for RW shares) and saves a copy into dump directory.
9. Keeps extensive log for deeper analysis.

Instructions:

1. Download archive.
2. Place it on any Windows machine with PowerShell ver. 2 or greater. Script is autonomous, BET are prepackaged. Thus there is no need to execute it from Ranger itself.
3. Extract files from archive.
4. Launch PowerShell console as administrator.
5. Allow script execution if necessary:
   Set-ExecutionPolicy unrestricted
6. Change directory to the script location, e.g. c:\BETreposync
7. Execute script
   .\reposync03

Note for users with DDBoost repositories.

DDBoost repos proved to be the slowest to import/sync. It does not mean though that this repo type shows bad performance during backup/restore.

The script reads 2 metadata files for each SP. Correspondingly BET metadata.exe is executed.

Just for comparison, single metadata call against CIFS repo takes less than a second. The best result for a single metadata call against DDBoost repo was 4.3 s.

Also there is an open bug for the case where metadata read takes 6 minutes. Devs are looking into the issue, there are few components to check: BET - cygwin - DDBoost API - Datadomain firmware.

Tested against vRanger 5.4/5.5 and 6.0.2. Script won't work for Ranger 5.3 or earlier version.

01/17/2014 Update. Minor bug for SP manifest reading has been fixed.

In contrast to reposync02 (still very popular), BET-based handles long SP path properly.

Why would I get an email from Quest Software Technical Support that has this as the subject line:

vRanger 6 is coming soon - Important Licensing Information

But the body of the email is an ad for Active Roles server??? WTF?

Discover Why ActiveRoles Server Is Your Key to Recurring Revenue. You Could Win a $50 Visa Gift Card!

Webcast: Adding Automation and Efficiency to User and Group Identity Management
Date: Wednesday, October 3
Time: 11 a.m. PT / 2 p.m. ET
Register for the webcast

Don’t miss this chance to see why so many service providers rely on ActiveRoles Server to deliver turnkey, targeted offerings with predictable recurring revenue upside.

Join leadership from our service provider partner program as they reveal how ActiveRoles Server can ease the daily burdens of managing your customers’ Windows environments. You could even win one of ten $50 Visa gift cards – just for attending this educational session!

Register now »

You’ll discover how our offering can help you:

Quest Software
5 Polaris Way
Aliso Viejo, CA 92656
USA

Phone: (800) 306-9329
Fax: (949) 754-8999
E-mail: info@quest.com

I recently upgraded from vReplicator 3 to vRanger 6.0.2 (or rather, stood up new service and created new jobs).

Ever since, the snapshot removal process takes at least 3x as long as it used to.  As a result some services that are picky are now stopping and/or losing connection to databases which is of course bad for the VMs that I'm replicating regardless of time of day.

I don't know what I can do to change this behavior unless it is the VA-HotAdd "feature" that is making it this extra slow.  The task 'Reconfigure Virtual Machine' isn't taking but 5 seconds, so that can't be it.

If this cannot be corrected I have no choice but to continue using vReplicator 3.x and re-enable all the old jobs.

Hello,

I've been looking around here a bit and did not find any answer on the following question:

I bought a new server for vRanger backups and I want to move now my existing vRanger 5.2.1 installation with all job settings and other setup from the existing server to the new one. Is there a guideline available to do this or could me somebode explain, how to do this?

I want to prevent it to create the backup jobs once again.

the vRanger database is stored on a separate SQL Server database server. If you need more Information about my setup to answer the question, please let me know.

Hi folks,

vranger pro 5 aktuall version.

when i will start the backup job comes after 19 sek. the error message

unable to lacate host.

I can ping the esxhost with name and ip.

some ideas

thanks for support

regards

dominik

I have five ESX4 hosts with about 80 VMs that I need to backup. On four of the hosts everything works just fine, but on the last one I cant get it to backup any VMs. I can see that snapshots are created OK, but every backup fails.

No further reason is given. Is there somewhere where i can se a log af what causes the failure?

I've tried picking one VM on the host, but that gives the same result.

Backup up with vRanger has been working smoothly on the old 3.5 environment, but now we are moving to a newer setup using ESX4 hosts.

Please, your feedback would be appreciated.

We recently upgraded one of ours envrionments from ESX 4.x to ESXi5 and also migrated to a new SAN with VMFS5 volumes.  vRanger is running on physical hosts that are presented the LUNs for LAN-Free backups.  Since the upgrade the backups have been failing on all VMs with the following error:

An internal error occurred during execution, please contact Vizioncore support if the error persists. Error Message: 2654 - can't read vix:r:(vcenter):902:[VMFS-LUN] VM-NAME/VM-NAME.vmdk:moref=vm-xxxxx:snapshot-xxxxxx:x [at io_size:125]

I suspect that it has something to do with the VMFS-5 filesystems.  I've been searching around and haven't been able to find a definitive answer as to if this is even supported in this version or not?

Does vRanger 6.0.2 support installation on Windows 2012?

The Installation guide support matrix seems to indicate only supporting up to 2008 R2, but my initial googling on the question shows that all of the press on vRanger 6.0 said that it would support installation on Windows 2012 upon its RTM.

Thanks!

Ranger GUI is lagging, not showing actual job state. I tried to trace events in vSphere Client, Ranger GUI and repository share at the same time.

I launched some backup job. Ranger shows it as queued for extended time.

VM is already snapshotted and var file is being written to repository - Job is still shown in Queue.

Eventually job moves to Running Tasks.

Snapshot has been commited, Savepoint seems to be finished (var and metadata files are done) - Job is still under 'Running' for almost 2 minutes.

This is especially noticeable for faster (incremental) jobs. Sometimes job does not even appears as running: queued for some time, then disappers. I find it under Successful.

Any suggestions?

Hello @all,

is there a feature list for vRanger V7 ?

Greets

Marco

Hi,

I have a vRanger backup from a ESX4 VM that I wish to restore to a completely different system and not located in anything managed or accessible by the vRanger that did the backup. Is it possible to restore from this vmdk.var file to .vmdk or at least something VMware workstation and ultimately ESXi 5 can run?

On the forums it appears that some extraction scripts/command line tools exist but the links are all to visioncore and those are broken. Could I use a trial version of VRanger 6 and do something here.

There are 3 files I can see in the vRanger backup copied to an external HD. It appears to be from vRanger v 4.5.2.16370

EMC_20121021_010007_F.Manifest.metadata

EMC_20121021_010007_F.VmConfig.metadata

EMC_20121021_010007_F_1_EMC-flat_vmdk.var

Part of the vmconfig follows

vRangerVersion>4.5.2.16370</vRangerVersion><CurrentSnapshot /><SnapshotLayouts /><VMConfig><changeVersion xmlns="urn:vim25">2012-10-13T23:53:41.168746Z</changeVersion><modified xmlns="urn:vim25">1970-01-01T00:00:00Z</modified><name xmlns="urn:vim25">EMC</name><guestFullName xmlns="urn:vim25">Ubuntu Linux (64-bit)</guestFullName><version xmlns="urn:vim25">vmx-07</version><uuid xmlns="urn:vim25">4230e631-b23b-01cd-83ed-2afd031cc393</uuid><instanceUuid xmlns="urn:vim25">50304715-cdbe-c5a1-11d2-bfc18080fd53</instanceUuid><npivWorldWideNameType xmlns="urn:vim25" /><npivTemporaryDisabled xmlns="urn:vim25">true</npivTemporaryDisabled><locationId xmlns="urn:vim25">564da9e8-622e-6303-3fc3-b6863b83e34a</locationId><template xmlns="urn:vim25">false</template><guestId xmlns="urn:vim25">ubuntu64Guest</guestId><alternateGuestName xmlns="urn:vim25">Ubuntu Linux (64-bit)</alternateGuestName><annotation xmlns="urn:vim25">vRanger Pro Backup: Type [Full] Result [Success] Time [2012/10/14 01:52:16 AM]

For some reason dll files (and possibly others) are greyed out and could not be restored during FLR.

Suggested workaround is to restore a parent folder with all files inside. This could be a time consuming task with large directories like System32.

There is another approach to this issue. As we know, during FLR Windows Guest disks are mounted to some temp directory under current user. We can browse to this location and pickup all necessary files.

'Side' effect to this approach is that searching mount point can be a viable alternative to the Catalog feature.

Catalog can be annoying, hard to install and manage feature requiring a separate local database. I'd rather delegate this feature (finding files) to standard Windows tools.

Yes, it is slower to search for files on the disk than get immediate location from the indexed DB. But how often do you restore files and do not know their location?

Another drawback is that Windows search won't locate files in multiple savepoints as Catalog does. Basically you need to launch FLR against some savepoint to be able to look for the files.

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.

================ update. 05/28/2013 ==================

New version of the script has been posted:
http://communities.quest.com/thread/23459?tstart=0

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.

Hello,

I had a problemwhenI wanted to make a filelevelrecovery (FLR)on alinuxVMwithLVMcontained multiple hard drive.

Inthedocumentation LVM with multiple hard drive is not supportedbyQuestbut Ioffer you myworkaround.

I hope this can help you

Kind regards,

Julien

Short answer is that Ranger vddk backup-restore cycle produces smaller and cleaner disk.

Here is a long answer.

Thin disk generally takes less space on datastore. VMware allocates more blocks as requested by Guest OS. Thus thin disk may grow all the way until it hits provisioned size. What happens when Guest OS releases space, say, user deleted a huge number of files? From thin disk size point of view – nothing! Disk won’t shrink. At the moment there is no way to easily reclaim free space (check addendum 1).

There is another factor here – the way Windows treats deleted files. As we know, Windows does not clean space occupied by the deleted file right away but simply marks file as deleted. There are 3^rd party tools (undelete, unerase, etc.) that can recover deleted files. Thus we can’t claim that when some file is deleted, the blocks, occupied by the file, are clean. Microsoft has a special tool to clean those blocks – sdelete (addendum 2).

Now we have a bloated thin disk with bunch of clean blocks. How can we reclaim that unused space and make thin disk smaller? As per addendum 1, there are few suggestions, but in my tests not all of them worked. Suggestions are:

1. Run sdelete in Windows Guest and power VM down.
   sdelete -c -z
2. Clone bloated disk using vmkfstools. It did not work for me.
3. Migrate VM (Storage vMotion) to a datastore with a different block size. It makes no sense if VMFS5 is in use.
4. Migrate VM to an NFS datastore. Worked for me.

Ideally you should see much smaller thin disk.

What does Ranger do? Let’s clarify, we are talking about one of the vddk modes (SAN, HotAdd, NBD), not about COS (Service Console) based.

VDDK is smart enough to tell a dirty block from clean. If a clean block is identified, VDDK simply drops it and advances to the next one. Then VDDK pipes dirty (legitimate) blocks to the Ranger compression utility. Obviously, during restore thin disk will be restored with dirty blocks only, thus taking less space than original disk.

I conducted a following test that demonstrates this behavior:

1. VM1 with a single thin disk (8GB) was created. Server 2003 OS was installed. Thin disk was at 1.4GB
2. 2GB file was copied to the Guest, then deleted. Thin disk was at 3.4GB
3. sdelete utility was executed. Thin disk bloated more, 6.8GB. That is how sdelete works.
4. For clarity VM1 was powered down.
5. Ranger backup (Machine-based VDDK LAN) was taken.
6. VM (VM2) was restored from the backup taken at step 5. Thin disk is 1.6GB
7. Backup of restored VM (VM2) was taken.
8. VM (VM3) was restored from the backup taken in previous step. Thin disk is of the same size as in step 6 – 1.6GB.
9. VM (VM2) restored at step 6 has the cleanest and smallest thin disk with no clean blocks. Size of VM3 is another proof: no more clean blocks.

And for the final, does VMware do anything to make reclamation easy? Yes there is some progress. VMware is introducing a new feature in vSphere 5.1 (addendum 3) to help reclaim free space in Guests.

1. Addendums.
2. http://www.virtualizationteam.com/virtualization-vmware/vsphere-virtualization-vmware/vmware-esx-4-reclaiming-thin-provisioned-disk-unused-space.html
3. http://technet.microsoft.com/en-us/sysinternals/bb897443.aspx
4. http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-51-Storage-Technical-Whitepaper.pdf
5. Commands to see a real size of a thin disk in ESX console:
   stat <disk>-flat.vmdk
   ls -asl <disk>-flat.vmdk
   du <disk>-flat.vmdk

I have a suggestion for the vRanger team.  I noticed that if a guest in a backup group becomes disconnected you will not get a failure alert for that guest.  There should be a failure alert if a guest becomes disconnected.  In my situation the sys admins moved some guest from one vCenter to another causing the guests in the job to become disconnected.  I was unaware of the move and the guests did not recieve a back for the period of time until I noticed that the guests had been moved.  I lost alot of backups because of this.  Is there any way that a failure alert can be made for this type of situation?