• State Not Answered
  • Locked Locked
  • Replies 6 replies
  • Subscribers 16 subscribers
  • Views 8567 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

vRanger 5.5.0.25454 - Backup Problem

achim.weiermann
over 6 years ago

Hello Forum,

I have a problem with the backup of an VM.

VRanger running on an physical Windows Server 2012 R2.

Virtual Software = VMware 5.5

VM1 = Windows Server 2008 R2 German incl. MS SQL Server 2008 Express Edition

VM2 = Windows Server 2012 R2 English incl. MS SQL Server 2012 Express Edition

Backup on an SCSI attached Storage MSA2012sa with enough space.

VM1 = scheduled task each saturday - always successfull

VM2 = scheduled taks on monday, wednesday, saturday - always failed

I just have deleted the task and set it up new, but that doesn't help.

No problems on the network.

I don't have any idea why.

Thanks Achim

If there is someone with an idea to resolve the problem that would be great.

  • 0 over 6 years ago
    Hello Achim, can you please provide the error message that you get within the task? Just look for the failed job, expand it, click on the task and get the log. We need to see this error in order to help you.

    In addition to this, vRanger 5.5 is no longer supported and it is currently EOL. What's the build version of the vCenter 5.5 server?
  • 0 over 6 years ago
    Hello Alexis,

    yes I know that the version 5.5 is out of life.

    But we have only 2 application from the german telekom they need the VMware virtualization.

    The VMware version is 5.5 Enterprise (latest version)

    Here the log file ov the VM2:
    2017-05-15 22:00:53.734]: vRanger Backup & Replication - v5.5.0.25454
    [2017-05-15 22:00:53.750]: Selected Options: Check destination for free space. | Compress backed up files. | Update notes with the latest backup results. | Enable Active Block Mapping (ABM). | Selected SpaceSavingTech: None | Included Disks [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64].
    [2017-05-15 22:00:53.750]: Task for virtual machine Concierge was queued.
    [2017-05-15 22:01:12.047]: SourceVm:Concierge | Uuid:564d3090-984e-f7b2-b646-a5f49036b966 | VC:N/A, Host:esx.peterhoff_nt.local [ESXi 5.5.0]
    [2017-05-15 22:01:12.047]: Beginning backup task for Concierge
    [2017-05-15 22:01:12.047]: Starting task validation.
    [2017-05-15 22:01:12.047]: Connection to esx.peterhoff_nt.local was properly validated.
    [2017-05-15 22:01:12.047]: esx.peterhoff_nt.local is properly licensed.
    [2017-05-15 22:01:12.063]: Test connection to repository VM-Backup starting...
    [2017-05-15 22:01:14.016]: Test connection to repository VM-Backup successful!
    [2017-05-15 22:01:14.406]: Ending task validation... success!
    [2017-05-15 22:01:14.406]: Beginning initialization of backup information.
    [2017-05-15 22:01:14.406]: Retrieving the tasks parent information.
    [2017-05-15 22:01:26.781]: Retrieving save points for any full backups associated with this job.
    [2017-05-15 22:01:26.906]: Finished initialization of backup information successfully.
    [2017-05-15 22:01:26.906]: A Full backup will be run for this task.
    [2017-05-15 22:01:26.984]: Gathering credentials for Concierge completed.
    [2017-05-15 22:01:26.984]: Checking for VMotion completed.
    [2017-05-15 22:01:27.156]: Gathering data for Concierge from API completed.
    [2017-05-15 22:01:27.984]: Gathering data for esx.peterhoff_nt.local from API completed.
    [2017-05-15 22:01:28.094]: Retrieving the VM BIOS configuration completed.
    [2017-05-15 22:01:28.547]: Checking free space on VM-Backup completed.
    [2017-05-15 22:01:33.219]: Creating a snapshot for vRanger completed.
    [2017-05-15 22:01:33.969]: Gathering data for Concierge from API completed.
    [2017-05-15 22:01:33.984]: Local machine is a physical machine.
    [2017-05-15 22:01:34.000]: Backup task will attempt to use Machine-based VDDK SAN.
    [2017-05-15 22:01:43.734]: Using filter type(s) active map for disk: vix:r:172.16.100.49:902:[datastore1] Concierge/Concierge.vmdk
    [2017-05-15 22:01:49.165]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [datastore1] Concierge/Concierge.vmdk
    [2017-05-15 22:01:49.166]: The failed backup task will be retried.
    [2017-05-15 22:01:54.835]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [datastore1] Concierge/Concierge.vmdk
    [2017-05-15 22:01:54.836]: The failed backup task will be retried.
    [2017-05-15 22:02:00.487]: Backup task using VDDK SAN failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [datastore1] Concierge/Concierge.vmdk
    [2017-05-15 22:02:00.488]: Backup task will be attempted using a Machine-based VDDK network connection.
    [2017-05-15 22:02:10.023]: Using filter type(s) active map for disk: vix:r:172.16.100.49:902:[datastore1] Concierge/Concierge.vmdk
    [2017-05-15 22:17:51.356]: Backing up disk 'vix:r:172.16.100.49:902:[datastore1] Concierge/Concierge.vmdk:moref=3:3-snapshot-2:6' completed.
    [2017-05-15 22:17:52.673]: Checking and enforcing retention policy completed.
    [2017-05-15 22:18:08.451]: Removing snapshot for vRanger completed.
    [2017-05-15 22:18:12.905]: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: The database trasaction was rolled back.


    Regards Achim
  • 0 over 6 years ago

    It looks like the database is full, can you please check what's the version of the SQL server and what's the size of the DB? If it is SQL 2005 express edition, the database cannot grow bigger than 4GB.

    Additionally, the 2nd VM is always failing. Does it have VMware tools up to date? Do you have an USB drive attached to the VM or a passthrough device? Is there any difference to the other VM? Are you using quiesce backups? If you are, do you see any error within the VSS writers?

  • 0 over 6 years ago
    vRanger DB
    The SQL Version is SQL Express 2008 R2 (10.50.6220). The DB limitation is 10 GB. But is this the limitation for the instance or for each database. In the instance there are 2 DB from the Report Server Modul and one DB named Catalog. Here are the size of the databases.
    Catalog = 2,81 MB
    ReportServer = 8,06 MB
    ReportServerTemp = 3,06 MB
    vRanger = 162,13 MB

    Yes the VMware tools are up to date. No there is no USB drive attached at the VM and no passtrough device. No we dont use quiesce backups and an error within the VSS writers is not displayed. The only difference to VM1 is the database version SQL Server 2008 (10.0.55.0).

    See the log from the VM1 here:
    [2017-05-13 21:00:59.164]: vRanger Backup & Replication - v5.5.0.25454
    [2017-05-13 21:00:59.164]: Selected Options: Check destination for free space. | Compress backed up files. | Update notes with the latest backup results. | Enable Active Block Mapping (ABM). | Selected SpaceSavingTech: None | Included Disks [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64].
    [2017-05-13 21:00:59.179]: Task for virtual machine DESK-UC was queued.
    [2017-05-13 21:01:04.070]: SourceVm:DESK-UC | Uuid:564dafea-23ed-1210-f820-be4ee95d9689 | VC:N/A, Host:esx.peterhoff_nt.local [ESXi 5.5.0]
    [2017-05-13 21:01:04.070]: Beginning backup task for DESK-UC
    [2017-05-13 21:01:04.070]: Starting task validation.
    [2017-05-13 21:01:04.070]: Connection to esx.peterhoff_nt.local was properly validated.
    [2017-05-13 21:01:04.070]: esx.peterhoff_nt.local is properly licensed.
    [2017-05-13 21:01:04.070]: Test connection to repository VM-Backup starting...
    [2017-05-13 21:01:04.539]: Test connection to repository VM-Backup successful!
    [2017-05-13 21:01:04.929]: Ending task validation... success!
    [2017-05-13 21:01:04.929]: Beginning initialization of backup information.
    [2017-05-13 21:01:04.929]: Retrieving the tasks parent information.
    [2017-05-13 21:01:05.101]: Retrieving save points for any full backups associated with this job.
    [2017-05-13 21:01:05.117]: Finished initialization of backup information successfully.
    [2017-05-13 21:01:05.117]: A Full backup will be run for this task.
    [2017-05-13 21:01:05.179]: Gathering credentials for DESK-UC completed.
    [2017-05-13 21:01:05.195]: Checking for VMotion completed.
    [2017-05-13 21:01:05.351]: Gathering data for DESK-UC from API completed.
    [2017-05-13 21:01:06.179]: Gathering data for esx.peterhoff_nt.local from API completed.
    [2017-05-13 21:01:06.289]: Retrieving the VM BIOS configuration completed.
    [2017-05-13 21:01:06.757]: Checking free space on VM-Backup completed.
    [2017-05-13 21:01:11.085]: Creating a snapshot for vRanger completed.
    [2017-05-13 21:01:11.820]: Gathering data for DESK-UC from API completed.
    [2017-05-13 21:01:11.835]: Local machine is a physical machine.
    [2017-05-13 21:01:11.851]: Backup task will attempt to use Machine-based VDDK SAN.
    [2017-05-13 21:01:20.992]: Using filter type(s) active map for disk: vix:r:172.16.100.49:902:[datastore1] DESK-UC/DESK-UC.vmdk
    [2017-05-13 21:01:26.304]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [datastore1] DESK-UC/DESK-UC.vmdk
    [2017-05-13 21:01:26.304]: The failed backup task will be retried.
    [2017-05-13 21:01:32.179]: Backup failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [datastore1] DESK-UC/DESK-UC.vmdk
    [2017-05-13 21:01:32.179]: The failed backup task will be retried.
    [2017-05-13 21:01:38.007]: Backup task using VDDK SAN failed: An internal error occurred during execution, please contact Quest support if the error persists. Error Message: 3201 - can't open [datastore1] DESK-UC/DESK-UC.vmdk
    [2017-05-13 21:01:38.007]: Backup task will be attempted using a Machine-based VDDK network connection.
    [2017-05-13 21:01:47.179]: Using filter type(s) active map for disk: vix:r:172.16.100.49:902:[datastore1] DESK-UC/DESK-UC.vmdk
    [2017-05-13 21:17:15.863]: Backing up disk 'vix:r:172.16.100.49:902:[datastore1] DESK-UC/DESK-UC.vmdk:moref=4:4-snapshot-5:6' completed.
    [2017-05-13 21:17:21.281]: Checking and enforcing retention policy completed.
    [2017-05-13 21:17:33.905]: Removing snapshot for vRanger completed.
    [2017-05-13 21:17:34.344]: Commiting savepoint data to VM-Backup completed.
    [2017-05-13 21:17:35.673]: Verifying the content of the repository completed.
    [2017-05-13 21:17:36.237]: Updating VM notes completed.
    [2017-05-13 21:17:36.466]: Setting VM event completed.

    The VMs are running very well on the VMware maschine.
  • 0 over 6 years ago
    I just have read in the post "Problems with vRanger 5.5 and ESXi 5.1 VM with virtual Hardware Version vmx-09?" that the network adapter cloud cause the failure. The VM1 has the network adapter E1000 and the VM2 has the network adapter VMXNET3. This adapter is recommended by the application. what do you think ?
  • 0 over 6 years ago
    Why don't you work through the regular support ticket? Engineer would enable service logging, collected failed task log and tell you what VM device/config causes the issue.
    Error is about converting VmConfig into xml format and storing copy in SavePointXml table. Older Ranger versions - and you are running pretty old one - did not know how to handle (read convert to xml) recently added parameters/hardware. Thus failure and rollback. The ugliest part of this behavior is that it occurs at the very end of the backup when all vars are successfully created. Years ago it was suggested to try/catch conversion at the very beginning. I do not know if Devs followed advice but I do not see the same error in recent Ranger versions that frequently.