Hi guys and Gals
A simple question.
Can vRanger backup ESXi 5 free edition housed guests.
Thanks you for your assistance
Regards
Mark
Hi guys and Gals
A simple question.
Can vRanger backup ESXi 5 free edition housed guests.
Thanks you for your assistance
Regards
Mark
Hello
Our vRanger 5.3 is backing up multiple VMs on multiple hosts without problems. Only one Linux VM on an ESXi 5.0 fails every time.
The messages in the log are:
[2012-02-22 09:10:49.425]: Gathering data for Srv03_Linux from API completed.
[2012-02-22 09:10:49.425]: Backup task will be attempted using a VDDK network connection.
[2012-02-22 09:54:26.269]: Backing up disk 'vix:r:192.168.145.51:902:[esx05_datastore2] Srv03_Linux/Srv03_Linux.vmdk:moref=vm-39253:snapshot-39727:3' completed.
[2012-02-22 09:54:28.675]: Checking and enforcing retention policy completed.
[2012-02-22 09:54:37.003]: Removing snapshot for vRanger completed.
[2012-02-22 09:54:43.769]: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: The database trasaction was rolled back.
The machine is copied over the network, but at the end something fails and the backup is deleted from the repository. I think the error message is misleading, as I have run SQL Profiler and could not see an SQL error.
Thank you very much for your help!
Hello,
i want to backup physical clients. I have to stop a service on this clients because
the vRanger aborts the job with errors when this service remains active.
When the vRanger job is finished, the service must restarting again.
Is there a possibility to achieve this goal automatically - for example, by script?
If so, how can i implement this?
Thank you!
Ruediger
vRanger Pro 5.2.1 backup gets to 33%, Then fails with error message: Index was outside the bounds of the array
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
What to be aware when you move from ESX to ESXi.
With more customers moving their infrastructure from ESX to ESXi (including version vSphere 5) I would like to cover one topic related to this upgrade.
I am not going to talk about a performance drop while moving from Service Console based (LAN) backup mode to the corresponding vStorage API NBD. This is all covered in Deployment guide along with some suggestions how to improve situation. We play by VMware rules: Service Console has been locked, end of story. We miss this part same way you do.
Here is another serious topic – Restore. Take following scenario. You had few ESX hosts and performed LAN-based backup. Some of your VMs had a snapshot or two. They were successfully backed up. With LAN-based backup we had an opportunity to save each vmdk file no matter if it was flat.vmdk or delta.vmdk (snapshot). During restore to the ESX host, all information is recovered including snapshots. Basically, after restore you still see a snapshot and have an option to revert or commit changes.
Now fast forward to ESXi. The only way to work with virtual disks is by using VMware vStorage API. You probably noticed already that if you backup VM with a snapshot residing on ESXi, you don’t see any delta files in savepoint directory. vStorage API consolidates all snapshots on the fly. What it means is that on restore you have a VM without any snapshots, with all changes, previously stored in snapshot, perfectly merged into the base flat vmdk.
If you try to configure a restore job from the savepoint with snapshots (delta files), job will fail:
[2012-04-04 15:31:38.383]: Restore task failed: Restoring savepoints with snapshots using VDDK is not supported.
[2012-04-04 15:31:38.415]: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: Restoring savepoints with snapshots using VDDK is not supported.
VDDK is just another term for vStorage API. Obviously, since it does not save snapshots during backup, why should it work with them on restore?!
What can we (Support) do to address this issue? Well, we have some options:
1. if you still have any ESX host you are saved. Just point a restore job to this host and run the job. VM will be restored with all snapshots.
2. we still have a manual restore procedure. Igor’s var-extractor restores vmdk on NTFS partition. It is a three-step procedure:
2.1 create VM with defined parameters (number of disks, size, number of snapshots);
2.2 extract vmdk from each var file locally, on Windows side;
2.3 upload all extracted vmdk to the datastore overwriting existing files.
It is a long and cumbersome procedure, but it does the trick.
There are two other possible solutions but both involve metadata editing. I won’t go into details, just give a brief description.
All references to the snapshot/delta should be removed from the Manifest and VmConfig files. Then ‘Restore from Manifest’ should be performed. Manifest file is pretty easy. The hard part is to properly edit VmConfig.metadata. Information about snapshot is stored in two major spots: at the very beginning (RootSnapshot, CurrentSnapshot/SnapshotLayouts) and in each disk configuration tag.
Here are two remaining solutions:
3. If you can leave snapshot behind (say, you do not care about changes accumulated in the snapshot), you can restore VM as if it never had a snapshot.
3.1 modify metadata files;
3.2 create ‘Restore from Manifest’ job.
4. If you still want to restore VM with all snapshots
4.1 modify metadata files;
4.2 create ‘Restore from Manifest’ job and run it;
4.3 take one or more snapshots of restored VM (see in metadata files how many snapshots existed);
4.4. extract delta files on Windows end using var-extractor. Make sure names match those created by VC/ESX in VM directory;
4.5 upload delta files to the datastore.
Every method, except for the first one, looks pretty complicated. And it is. Main goal of this post is to make customers aware of possible issues during restore.
Keeping VMs clean of any snapshots helps avoiding problems in the future!
Hi all,
I upgraded to vRanger 6 and after that the Email notifications after task completion are no longer sent.
SMTP settings are verified to be correct and test emails are sent without issue.
I found a KB about the same problem in vRanger 5.2 (https://support.quest.com/SolutionDetail.aspx?id=SOL89326), but the solution doesn't work
Anyone who can help me?
Thanks in advance!
Sascha
Few customers are concerned with the fact that scheduled reports in Ranger 6.1.0 disappear after service restart. On-demand reports seem to be ok.
This bug will be fixed in v. 7.x
I posted one alternative method before (http://communities.quest.com/thread/25191?tstart=0). MS Access can be used to generate various reports.
Meantime I decided to look at what Ranger GUI normally provides. Well, frankly speakling, we can do better.
There are few things that need improvements. For example, Backup Task Report:
Long story short. Attached is a powershell script that will create a report equivalent to Backup Task Report.
Advantages:
Instructions:
Here are few screenshots:
Backup Task report in IE.
Mini SavePoint report as email with html body. Following SELECT was used:
$SqlCmd.CommandText = "select top 100 VmName, StartTime, SizeInMbOriginal, SizeInMbStored from savepoint where IsDeleted = 0 order by VmName, StartTime"
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]
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
Good day,
I am unable to perform a File Level Restore operation with vRanger 5.3. Full restore operations complete without any problems. When I try to start a File Level Restore for a particular guest machine I see a, "Error Mount Failed," message in the File Level Restore screen. When I look in the Windows application log I see the following error:
Source: VizionCore FLR
Event#: 0
Message: FATAL cifs_cant_use CIFS cannot connect to share
I've looked at the following articles but they don't seem to help:
https://support.quest.com/SolutionDetail.aspx?id=SOL76701&pr=vRanger
https://support.quest.com/SolutionDetail.aspx?id=SOL91212
https://support.questsoftware.jp/SolutionDetail.aspx?ID=SOL93336
Details:
I am logging into the Windows server as local administrator.
The service account that vRanger runs under is part of the local administrator group.
The repository that is being backed up to is a Linux-based storage server.
The account that I use to access the share on the Linux server has full access permissions on the share (I can mount/read/write from the Windows server just fine).
The share is set to public, writable, readable, and browseable.
There is no firewall between the Windows server and the Linux server.
I find it extremely strange that I can do a full restore just fine, but cannot perform a file level restore. What is different about the two operations? What is the problem?
We run a vRanger 6.0.1 nightly job to back up approximately 180 VMs residing across 4 vSphere 5.1 hosts. Every morning there are several VMs in vCenter that show up with the "virtual machine disks consolidation is needed" yellow exclamation warning on them. It is not always the same VMs, just a random handful every night. Manual consolidation is needed on them as the delta files are left on the VMs. The vRanger task log for a problem VM indicates no problems, "Removing snapshot for vRanger completed." There isn't a single error throughout the task log. So from the vRanger standpoint, it thinks it completed correctly. I assume this is because of poor error handling however as if you look at the events for the VM in question in vCenter, coinciding at the same time as vRanger removing the snapshot line in its log, you see events for "Task: Remove snapshot" followed within seconds by "Virtual machine disks consolidation is needed" followed immediately by "Virtual machine disks consolidation failed." So the reference to the snapshot is being removed but consolidation fails leaving the snapshot in an orphanned ghosted state and growing until manual consolidation is performed.
All of these VMs that experience this problem are using Machine-based VDDK SAN "HotAdd" so I am assuming that the physical server that runs vRanger is not letting go of the VMDK before consolidation is attempted so the VMDK lock is preventing the consolidation from occurring. The SANs in question are a pair of EqualLogics connected via iSCSI to both the vSphere hosts and the physical server that runs vRanger.
Any ideas how to prevent this from happening?
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
Hello all,
I'm trying to use PS command line to add replication jobs, not having much luck. Has anyone gotten this working?
I've set my $vm to my vmguest and $vmhost to ESXHost.
Here's my command line that is failing with error:
CMD>
Add-ReplicationJobTemplate -JobName DR_RepJob_$vm -JobEntity $vm -TargetHost $vmhost -ReplicateName $vm"_DR" -Type Differential -targetDatastores DS_Dataxxx, DS_Dataxxx -PrimaryDatastore DS_dataxxx -targetnetworks dvPortGroup_xxxx -flags CheckDestinationFreeSpace, UseCompression
error "Unable to AddReplicationJob: {0}Object reference not set to an instance of an object"
Additionally, can someone point me to full documentation of CMDLETS? the get-help seems rather slim with information. I'd like to add the -JobSchedule parameter too but so far have not found any documentation for using it?
Thanks
Hi,
I am fairly new to vranger and have just started using it to backup or VDI VMs. I seem to be running out of space and someone else that uses it seemed to be saying that it doesn't delete old backups. Is this true? I really just want to keep 2weeks of backups, so say 2 full backups and differentials the rest of the time. I have tried to configure this, however even so, it I am running out of space on the backup device. It seems to me like it isn't cleaning up old backups.
Can anyone confirm or deny this for me please? Ans what settings wouuld I use to have 2 weeks of backups with a full backup every 7 days and incrementals on the days there is no full backup?
Thanks
Hello,
I'm Using ESXi 4.1 and Vranger installed in physical Machine with Server 2008R2, Vcenter and direct ISCSI access ( VMDK Files are stored on DELL MD3220i Storage).
First, this is a continue to the Thread http://communities.quest.com/thread/14619
Vranger before 5.3, when Backup SRV2008 VM, check that enable disk.EnableUUID is set to "false". So no Application Level Quiescing. Ony he Method with vzshadow, see here: https://support.quest.com/SolutionDetail.aspx?id=SOL93858 worked. But also only withenable disk.EnableUUID is set to "false.
Since Version 5.3, Vranger like to have this setting enabled. Ok, no Problem. But when I enable Guest Quiescing in the Backup Job, i will get error Message like:
Error Message: 2800 - filter file contains the wrong number of blocks
and
Catalog data for [LUN_3 RAID5] xxxxx.vmdk volume 1 failed to save for the following reason(s): Catalog command failed: An internal error occurred during execution, please contact Quest support if the error persists.
Error Message: 3201 - can't open [LUN_3 RAID5]xxxx.vmdk
I just tested one new Backup Job, new vranger 5.5 install.
Backup Option: Incremental, Compress, Enable ABM, Enable Catalog, Automatic Transfer > SAN Based.
Backup Job finished without Errors.
When I then enable The Option Guest Quiescing, the above Error Messages appears.
When will this sometime Fixed?
Case ID : 1030409
Hi Everyone,
I have a short Question about vRanger 5.5 and the new VMware ESXi 5.1 Servers.
I have one new ESXi 5.1 Server and migrated a VM on this new System. I also upgraded the Hardware of the VM from Hardware-Version 8 to Hardware-Version vmx-09.
It seems that since that upgrade i can not backup my VM any more with the current vRanger Version (5.5). I also tried to delet the backup job and made a new one, but this didn't help.
Is there a compatonolity issue? Are vmx-09 not supported at the moment? Will it just work with vRagner 6? And if yes, when will be vRanger 6 released? =)
Thanks for your help!
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