Network Backup Version 9.1 VMware vStorage/vCenter Guide

From Arkeia Documentation

Jump to: navigation, search

Contents

VMware vStorage Introduction

The vStorage APIs for Data Protection enable backup software to perform centralized virtual machine backups without the disruption and overhead of running backup tasks from inside each virtual machine.

Arkeia VMware vStorage Agent Introduction

By integrating with VMware's vStorage APIs, Arkeia Software offers a solution for protecting VMware environments that is fast, easy to use, and affordable. Combined with the vStorage API, Arkeia Network Backup enables next-generation virtual machine backup. For older versions of VMware that do not support the vStorage APIs, a console-based agent is available. This agent installs directly in the hypervisor and can perform full image-level snapshots of multiple virtual machines while they are running.

By leveraging VMware's vStorage API, the VMware Backup Agent is able to perform proxy-less backups of VMware virtual machines. No longer is a Windows proxy server required to stage the backups, as was the case with VMware Consolidated Backup (VCB), resulting not only in faster backups, but also reduce storage requirements. The VMware Backup Agent also supports multiple transport methods that enables LAN-free backup over the SAN. Block-level incrementals further enhances performance by backing up only the changed blocks within a virtual machine.

The VMware Backup Agent is able to perform virtual machine backups and recoveries without requiring a backup agent to be installed on each virtual machine. A single agent enables consolidated management of multiple virtual machines for all backup and recovery operations. The Agent is also compatible with VMware vCenter to enable support for multiple ESX hosts. By not requiring a backup proxy for staging, the VMware Backup Agent removes a lot of the complexity that is associated with VCB based backups. Furthermore, file-level restores can be performed from image-level backups without requiring additional file-level backups.


Supported VMware Platforms

VMware Infrastructure 3 
* ESX 3.x
* ESXi 3.x    (see ESXi notes)
* Virtual Center 2.x
 
VMware vSphere 4.0 
* ESX 4.0
* ESXi 4.0    (see ESXi notes)
* vCenter 4.0
      
VMware vSphere 4.1
* ESX 4.1
* ESXi 4.1    (see ESXi notes)
* vCenter 4.1

 VMware vSphere 5
* ESX 5.0
* ESXi 5.0    (see ESXi notes)
* vCenter 5.0

VMware VDDK API Support Notes and Programing Guides

VMware's APIs and VMware's policy supports up to two former versions.
When they release a new major version of vSphere (3.0, 3.5, 4.0, 4.1, 5.0), the corresponding API released at the same time supports up to 2 former versions.

  • VDDK 1.1.1 was released for vSphere 4.0 and it supports vSphere 4.0 / Virtual Infrastructure 3.5 and Virtual Infrastructure 3.0
  • VDDK 1.2.1 was released for vSphere 4.1 and it supports vSphere 4.1 / 4.0 and Virtual Infrastructure 3.5
  • VDDK 5.0 was released for vSphere 5.0 and it supports vSthere 5.0 / 4.1 / 4.0 and Virtual Infrastructure 3.5



Arkeia VDDK API Version Support Notes

Arkeia v8.2.4 to v8.2.8

Arkeia v8.2.4 to v8.2.8 embeds VDDK 1.1.1 and supports the following environments. 

VMware Infrastructure 3.x
* ESX 3.x
* ESXi 3.x    (see ESXi notes)
* Virtual Center 2.x

VMware vSphere 4.0 
* ESX 4.0
* ESXi 4.0    (see ESXi notes)
* vCenter 4.0

Arkeia v8.2.9 to v9.0.15

Arkeia v8.2.9 to v9.0.15 embeds VDDK 1.2.1 and supports the following environments. 

VMware Infrastructure 3.5
* ESX 3.5
* ESXi 3.5    (see ESXi notes)
* Virtual Center 3.5

VMware vSphere 4.0 
* ESX 4.0
* ESXi 4.0    (see ESXi notes)
* vCenter 4.0
     
VMware vSphere 4.1
* ESX 4.1
* ESXi 4.1    (see ESXi notes)
* vCenter 4.1

Arkeia v9.0.12 to v9.1.0

Arkeia v9.0.12 embeds VDDK 5.0 and supports the following environments. 

VMware Infrastructure 3.5
* ESX  3.5
* ESXi 3.5    (see ESXi notes)
* Virtual Center 3.5

VMware vSphere 4.0 
* ESX  4.0
* ESXi 4.0    (see ESXi notes)
* vCenter 4.0
     
VMware vSphere 4.1
* ESX  4.1
* ESXi 4.1    (see ESXi notes)
* vCenter 4.1

VMware vSphere 5.0
* ESX  5.0
* ESXi 5.0    (see ESXi notes)
* vCenter 5.0

ESXi Notes

ESXi is a no-cost, bare-metal hypervisor version of VMware Hyper Visor which does not include a console.

The VMware vStorage license is NOT included in the ESXi with a Free license expect during the trial period.
The vStorage license can be purchased as part of the VMware vSphere Essentials from VMware and is a prerequisites for the Arkeia vStorage Agent.

Supported Platforms

Arkeia's vStorage Agent supports the following platforms as designated by VMware's Support Platform Policy per VDDK Release Notes.

VDDK 1.1.1

Arkeia v8.2.4 to v8.2.8 embeds VDDK 1.1.1

Please refer to the VMware Developer VDDK 1.1.1 Release Notes for more details about support platforms. 

Windows XP (SP3)           (Intel/AMD x86)
Windows Vista              (Intel/AMD x86)
Windows Vista              (Intel/AMD x86-64)
Windows Server 2003        (Intel/AMD x86-64)
Windows Server 2003        (Intel/AMD x86)
Windows Server 2008        (Intel/AMD x86-64)
Windows Server 2008 R2     (Intel/AMD x86-64)
Linux Redhat RHEL 5.x      (Intel/AMD x86-64)
Linux Redhat RHEL 5.x      (Intel/AMD x86)
Linux Novell SLES 10       (Intel/AMD x86-64)
Linux Novell SLES 10       (Intel/AMD x86)

VDDK 1.2.1

Arkeia v8.2.9 to v9.0.7 embeds VDDK 1.2.1

Please refer to the VMware Developer VDDK 1.2.1 Release Notes for more details about support platforms. 

Windows XP (SP3)         (Intel/AMD x86)
Windows Vista            (Intel/AMD x86)
Windows Vista            (Intel/AMD x86-64)
Windows Server 2008      (Intel/AMD x86-64)
Windows Server 2008 R2   (Intel/AMD x86-64)
Windows Server 2003      (Intel/AMD x86-64)
Windows Server 2003      (Intel/AMD x86)
Windows 7                (Intel/AMD x86-64)
Windows 7                (Intel/AMD x86)
Linux Redhat RHEL 5.x    (Intel/AMD x86-64)
Linux Redhat RHEL 5.x    (Intel/AMD x86)
Linux Novell SLES 10     (Intel/AMD x86-64)
Linux Novell SLES 10     (Intel/AMD x86)
Linux Novell SLES 11     (Intel/AMD x86-64)
Linux Novell SLES 11     (Intel/AMD x86)
Linux Novell OES2        (Intel/AMD x86-64)
Linux Novell OES2        (Intel/AMD x86)

VDDK 5.0

Arkeia v9.0.12 and higher embeds VDDK 5.0

Please refer to the VMware Developer VDDK 5.0 Release Notes for more details about support platforms. 

Windows XP (SP3)                   (Intel/AMD x86)
Windows Vista                      (Intel/AMD x86)
Windows Vista                      (Intel/AMD x86-64)
Windows Server 2008                (Intel/AMD x86-64)
Windows Server 2008 R2             (Intel/AMD x86-64)
Windows Server 2003                (Intel/AMD x86-64)
Windows Server 2003                (Intel/AMD x86)
Windows 7                          (Intel/AMD x86-64)
Windows 7                          (Intel/AMD x86)
Windows 8                          (Intel/AMD x86-64)
Windows 8                          (Intel/AMD x86)
Linux CentOS 5.5                   (Intel/AMD x86-64)
Linux CentOS 5.5                   (Intel/AMD x86-64)
Linux Redhat RHEL 5.3, 5.4, 5.5    (Intel/AMD x86-64)
Linux Redhat RHEL 5.3, 5.4, 5.5    (Intel/AMD x86)
Linux Redhat RHEL 6.0              (Intel/AMD x86-64)
Linux Redhat RHEL 6.0              (Intel/AMD x86)
Linux Novell SLES 10               (Intel/AMD x86-64)
Linux Novell SLES 10               (Intel/AMD x86)
Linux Novell SLES 11.0             (Intel/AMD x86-64)
Linux Novell SLES 11.0             (Intel/AMD x86)
Linux Ubuntu 10.04                 (Intel/AMD x86-64)
Linux Ubuntu 10.04                 (Intel/AMD x86)

Supported Backup Types

Image Level Full Backups

Arkeia supports a Full Image level backup of all Virtual Machines when the backup type is set to Total or Archive. During a Total or Archive full backup, Arkeia will backup and restore the entire Virtual Machine image.

If your VM Image has 100 GB allocated but the used blocks are only 20 GB, a Full Image level backup will backup and restore the entire 100 GB VM allocated image.

Image Level Thin-Full Backups (CBT)

Arkeia supports Thin-Full Image level backups of all Virtual Machines when the backup type is set to Total or Archive and when the CBT (Change Block Tracking) option is set. During a Thin-Full backup, Arkeia will only backup and restore ONLY the used blocks within the Image.

If your VM Image has 100 GB allocated but the used blocks are only 20 GB, a Thin-Full Image level backup will ONLY backup and restore the used blocks and not the entire VM Image.

  • CBT Thin-Full backups are supported on ESX 4 and the Virtual Machine's Hardware Version 7 and higher.

Image Level Differential Backups (CBT)

Arkeia supports Differential Image level backups of all Virtual Machines when the backup type is set to Differential and when the CBT (Change Block Tracking) option is set. During an Differential backup, Arkeia will only backup the changed blocks that have occurred since the last Total backup.

  • CBT Differential backups are supported on ESX 4 and the Virtual Machine's Hardware Version 7 and higher.

Image Level Incremental Backups (CBT)

Arkeia supports Incremental Image level backups of all Virtual Machines when the backup type is set to Incremental and when the CBT (Change Block Tracking) option is set. During an Incremental backup, Arkeia will only backup the changed blocks since the last backup which can be a Total, Differential or Incremental.

  • CBT Incremental backups are supported on ESX 4 and the Virtual Machine's Hardware Version 7 and higher.

Data Transport Modes

When backing up from an Hypervisor, the need for a LAN connection between the backup machine and the hypervisor is required even if you're using a LAN-free transport mode (SAN or HOTADD).

When backing up from a vCenter (several hypervisors seen as one), the backup client needs to connect to the vCenter through the LAN, but also needs to be able to make a direct connection to the hypervisors hosting the virtual machines to backup. If the NBD (LAN) or NBDSSL (SSL LAN) transport modes are used, the data will not be transferred through the vCenter API which that would make the transfer of data extremely slow.

This does not apply to SAN and HOTADD modes.

Supported Transport Modes

SAN       Supported
HOTADD    Supported
NBD       Supported
NBDSSL    Supported

The Arkeia vStorage Agent supports the following data transport methods which are configurable "Advanced Options" at the Savepack level. The Arkeia Administrator can modify the Savepack and set the "Data Transport" priority method required by their environment.

SAN

The SAN option is the primary data transport method in the Savepack setting.
When the ESX Server and the backup server are connected via SAN, the SAN (Fiber Channel or iSCSI) is used for data transportation enabling LAN-Free Backups.
There is no known disk size limitation.

The SAN Transport Layer is supported by VMware and Arkeia on the following platforms. 

Arkeia v8.2.4 to v8.2.8 embeds VDDK 1.1   VMware Developer VDDK 1.1.1 Release Notes


Windows Server 2003        (Intel/AMD x86-64)
Windows Server 2003        (Intel/AMD x86)
Windows Server 2008        (Intel/AMD x86-64)
Windows Server 2008 R2     (Intel/AMD x86-64)
Linux Redhat RHEL 5.x      (Intel/AMD x86-64)
Linux Redhat RHEL 5.x      (Intel/AMD x86)

Arkeia v8.2.9 to v9.0.7 embeds VDDK 1.2  VMware Developer VDDK 1.2.1 Release Notes

Windows Server 2003        (Intel/AMD x86-64)
Windows Server 2003        (Intel/AMD x86)
Windows Server 2008        (Intel/AMD x86-64)
Windows Server 2008 R2     (Intel/AMD x86-64)
Linux Redhat RHEL 5.x      (Intel/AMD x86-64)
Linux Redhat RHEL 5.x      (Intel/AMD x86)
Linux Redhat RHEL 6.0      (Intel/AMD x86-64)
Linux Redhat RHEL 6.0      (Intel/AMD x86)

Arkeia v9.0.10 and higher embeds VDDK 5.0    VMware Developer VDDK 5.0 Release Notes

Windows Server 2003        (Intel/AMD x86-64)
Windows Server 2003        (Intel/AMD x86)
Windows Server 2008        (Intel/AMD x86-64)
Windows Server 2008 R2     (Intel/AMD x86-64)
Linux Redhat RHEL 5.x      (Intel/AMD x86-64)
Linux Redhat RHEL 5.x      (Intel/AMD x86)
Linux Redhat RHEL 6.0      (Intel/AMD x86-64)
Linux Redhat RHEL 6.0      (Intel/AMD x86)
Linux CentOS 5.x           (Intel/AMD x86-64)
Linux CentOS 5.x           (Intel/AMD x86)
Linux CentOS 6.0           (Intel/AMD x86-64)
Linux CentOS 6.0           (Intel/AMD x86)
Linux SLES 11              (Intel/AMD x86-64)
Linux SLES 11              (Intel/AMD x86)

HOTADD

The HOTADD option is the secondary data transport method in the Savepack setting.
Virtual machines designated as backup servers incur unnecessary traffic when backing up other virtual machines.

  • With this mode, the VM containing Arkeia vStorage agent must not be backed up!
  • HOTADD does not support IDE Disk.

Since virtual machines share the same resources they are able to transfer data to and from each other without having to use network protocols. VMware provides this capability via the "hot-add transport methods" which allows a virtual machine to directly mount the block storage devices of other virtual machines for direct-access. This method provides enhanced backup speeds and would reduce the amount of traffic on the network.

vSphere 5.0 HOTADD Licensing Note
In vSphere 5.0, the SCSI HotAdd feature is enabled only for vSphere editions Enterprise and higher, which have Hot Add licensing enabled. No separate Hot Add license is available for purchase as an add-on. In vSphere 4.1, Hot Add capability was also allowed in Advanced edition. Therefore, customers with vSphere Essentials or Standard edition who use backup products (including VMware Data Recovery) are not able to perform proxy-based backup, which relies on SCSI HotAdd. Those customers must use alternate transport modes.


Please refer to VMware VDDK Release Notes for more details about Vmware HOTADD Transport Mode support.

NBD

The NBD option is the third data transport method in the Savepack setting.
When a SAN or HOTADD environment is not present, the data is sent over the local LAN.
NBD uses the hypervisor resource (CPU, LAN).

  • NBD does not support disks larger than 1TB according to the VDDK 1.1.1, 1.2.1 and 5.0 API documentation.

NBDSSL

The NBDSSL option is the fourth data transport method in the Savepack setting.
The Administrator can modify the Savepack and set the "Data Transport" priority method required by their environment.
NBDSSL uses the hypervisor resource (CPU, LAN).

  • NBD does not support disks larger than 1TB according to the VDDK 1.1.1, 1.2.1 and 5.0 API documentation.
  • Reference VDDK Documentation Center

Change Block Tracking (CBT)

Change Block Tracking (CBT) is a VMkernel feature that keeps track of the storage blocks of virtual machines as they change over time.
Because of this feature, a couple of functions are way more efficient on VMware’s vSphere 4 platform than previous Virtual Infrastructure 3.

The VMkernel keeps track of block changes on virtual machines, which enhances the backup process for applications that have been developed with VMware’s vStorage APIs. The VMkernel’s Change Block Tracking (CBT) enhances VMware’s Storage VMotion because the process no longer consumes double the amount of resources per virtual machine.

Reset & Enabling CBT for Arkeia

Arkeia Supports CBT which may need to be reset if another application has already performed a snapshot and enabled CBT on the VM.
When the ctkEnabled values are set to "FALSE", the first Arkeia backup using CBT will enable then by setting the value to "TRUE".

  • The VM must be running Virtual Machine Version 7.

The first step is to enable CBT on a per-VM basis. 

* Power OFF your VM
* Delete all VM snapshots that you have on disk if there are any 
* Open the VMware vSphere Client
      - right-click the VM
      - choose Edit Settings -> Options tab
      - select General
      - click Configuration Parameters
      - set ALL ENTRIES with ‘ctkEnabled’ substring to FALSE including disk entries

         scsi0:0.ctkEnabled = "FALSE"
         scsi0:1.ctkEnabled = "FALSE"
         ctkEnabled = "FALSE"

* Power ON the VM 
* Start a Total Arkeia Backup of the VM
* Start an Incremental Backup (based on the Total Backup) using CBT to initiate Change Block Tracking on the VM

Limitations of CBT

Changed Block Tracking does not work in any of the following cases according to VMware.

  • Virtual hardware version is 6 or earlier.
  • The virtual disk is a “physical compatibility RDM.”
  • The virtual disk must not be (persistent or non-persistent) independent disk, meaning unaffected by snapshots.
  • The virtual disk is attached to a shared virtual SCSI bus.

Changed Block Tracking can be enabled on virtual machines that have disks like these, but when queried for their change ID, these disks always return an empty string.
So if you have a virtual machine with a regular “O/S disk” and a pass‐through RDM as a “data disk” you can track changes on the “O/S disk” only.

Reference: VMware vSphere Backup Guide

Virtual Machine Disk Backup Support

The type of a hard disk determines if the backup can be performed online and/or offline.

Virtual Disks

Virtual Disk Mode Summary

Independent Mode Powered ON  = ONLINE BACKUP IS NOT SUPPORTED
Independent Mode Powered ON  = CBT IS NOT SUPPORTED
Independent Mode Powered OFF = Disk backup is supported
Independent Mode Powered OFF = CBT is supported

Dependent Mode Powered ON  = no known limitations
Dependent Mode Powered ON  = no known limitations
Dependent Mode Powered OFF = no known limitations
Dependent Mode Powered OFF = no known limitations

Independent Mode

Virtual Disk (dependent and independent mode) are the "classic" virtual machine disk made of files in a data store located on local storage, NDF and SAN disk.
A backup of these disks are accomplished while the Virtual Machine is powered on.

Some virtual disks may be in "independent mode" which does not support snapshots.
If the VM is powered on during the shapshot / backup process, some data can still be written to this disk and as the disk is "in use" and cannot be opened by the backup agent. In this situation, the Arkeia vStorage agent will report a warning message: 

arkeia-vsphere4: my virtual machine: cannot backup disk 'Hard disk 2' while the virtual machine is powered on

If the virtual machine is powered off, then it is possible to backup this type of disk. No warning message is reported and the whole content of this disk is saved. Other disks of that same VM that can be snapshoted, are always snapshoted and the backup reads the data from their snapshoted image.

The use of CBT for one disk depends on the snapshot. If the disk cannot be snapshoted (independent disk), then there will be no CBT for that disk. If you've selected the CBT feature in the savepack and you're asking an incremental backup of the VM, for this "independent disk" it will always be a full (and thick) backup.

Dependent Mode

There are no known limitations when the Virtual Disk is in Dependent Mode

Raw Device Mapping (RDM)

A Raw Device Mapping gives a virtual machine direct access to the SAN and allows you to use existing SAN commands to manage the storage. 

RDM Disk Mode Summary

RDM Physical Mode Powered ON  = ONLINE BACKUP IS NOT SUPPORTED
RDM Physical Mode Powered ON  = CBT IS NOT SUPPORTED
RDM Physical Mode Powered OFF = Disk backup is supported
RDM Physical Mode Powered OFF = CBT is supported in this mode

RDM Virtual Mode Powered ON  = no known limitations
RDM Virtual Mode Powered ON  = no known limitations
RDM Virtual Mode Powered OFF = no known limitations
RDM Virtual Mode Powered OFF = no known limitations

RDM in Physical Compatibility Mode

pRDM or Physical RDM allows the guest operating system to access the hardware directly.

These type of disks do not support snapshots as they behave like the Virtual Disk in Independent Mode.
Arkeia will therefore treat them like the Independent Mode Virtual Disks which can only be backed up when the VM is powered off.

RDM In Virtual Compatibility Mode

vRDM or Virtual RDM allows the virtual machine to use VMware snapshots and other advanced functions

These disks are compatible with the way VMware works with the "classic" Virtual Disks with Snapshots and CBT being fully supported while the VM is powered on.

Virtual Machine Disk Restore Notes

Restoring An RDM (Physical or Virtual)

When restoring a virtual machine that had an RDM at backup time, the RDM is restored as a classic virtual disk on a datastore rather than to a raw disk on the SAN.
The result is that the space used by the VM on the datastore where it is restored will be higher than the used space at backup time.

Restoring A Virtual Disk in Independent Mode or A Physical RDM

  • If the virtual machine was powered on during the backup, then the disks in independent mode (like a physical RDM) could not be backed up. Therefore, the virtual machine is restored without these disks.
  • If the virtual machine was powered off at backup time, these disks could be backed up and are therefore restored.

The Backup Process

VDAP Process

VADP executes the following steps when a backup process is called:

  • Quiesce the filesystem
  • Create a Delta file
  • Begin writing all data to the delta file
  • Backup the original VMDK
  • After the completion of the backup merge the two files
  • Delete the delta file

Backup the Virtual Machine

When a virtual machine is selected in a Savepack, the virtual machine's configuration and all its virtual disks will be backed up.

The vStorage Agent:

  • creates a snapshot for Arkeia named "arkeia-snapshot"
  • the virtual machine configuration is backed up from the snapshot
  • each hard disk of the VM's snapshot is backed up using the VDDK
  • Once all disks are backed up, the snapshot "arkeia-snapshot" is deleted.

The snapshot asks the virtual machine to quiesce the file systems and the VSS applications.
Creating and removing a snapshot may last a few minutes.

Backup A Hard Disk of a Virtual Machine

The Arkeia vStorage Agent supports the backup of virtual machine hard disk.

The vStorage Agent:

  • creates a snapshot for Arkeia named "arkeia-snapshot"
  • ONLY THE SELECTED hard disk of the VM's snapshot is backed up using the VDDK
  • the selected disks are backed up, the snapshot "arkeia-snapshot" is deleted.


WARNINGS!
If several hard disks of the same virtual machine are selected, a snapshot will be made for each hard disk.
Consistency between two backed up disks of a VM is not guaranteed because they were not snapshoted at the same time. 

EXAMPLE: 
Consider a Virtual Machine with 2 hard disks configured in RAID1. 
While they should be the same, the first and the second disks will not be the same if there has been some disk activity 
between the 2 snapshots/backups.

Multi Flow backups of two selected disk are NOT SUPPORTED!
 There can be only one snapshot named "arkeia-snapshot" at a time so there will be a conflict when the backup of the second hard disks starts while the first is still processing.

Data Processing

Single Tree Per Host

  • When the Savepack trees are the "!vStorage:/xx.xx.xx" there is only one flow used per ESX host which is the default behavior.
  • All virtual machines are backed up one after the other per host.
  • The guest hosting the vStorage Agent must be omitted from the backup job as it is not possible to backup a Virtual Machine hosting the vStorage Agent while backing up other VMs. 
backup.us.arkeia.com!vStorage:/192.168.5.201
backup.us.arkeia.com!vStorage:/192.168.5.202

Virtual Machines As Trees

  • When the Virtual Machines are the Savepack trees, one flow is used by default per ESX host.
  • All virtual machines are backed up one after the other per host.
  • This type of savepack tree would process the same as the "single flow per host" method.
  • The guest hosting the vStorage Agent must be omitted from the backup job as it is not possible to backup a Virtual Machine hosting the vStorage Agent while backing up other VMs. 
backups.us.arkeia.com!vStorage/192.168.5.201/Arkeia Appliance         Flow = 0 (default)
backups.us.arkeia.com!vStorage/192.168.5.201/Windows 2003 Server      Flow = 0 (default)
backups.us.arkeia.com!vStorage/192.168.5.201/CentOS 5.3               Flow = 0 (default)
backups.us.arkeia.com!vStorage/192.168.5.201/Solaris 10 x86           Flow = 0 (default)
backups.us.arkeia.com!vStorage/192.168.5.202/Web Apps                 Flow = 0 (default)
backups.us.arkeia.com!vStorage/192.168.5.202/Exchange 2007            Flow = 0 (default)
backups.us.arkeia.com!vStorage/192.168.5.202/RHEL 5.4                 Flow = 0 (default)
backups.us.arkeia.com!vStorage/192.168.5.202/Sharepoint Server        Flow = 0 (default)

Multi Flow Per Virtual Machine

  • When the Virtual Machine are the Savepack trees, and multi flow is used.
  • All virtual machines are backed up at the same time using multiple data streams.
  • WARNING! the muti-flow method of all VMs on a single ESX Host can depreciate the performance of the ESX host
  • WARNING! this method is NOT recommended if the vStorage Agent is installed on the backup server unless you have enough CPU and MEMORY to handle the extra processes. Keep a close eye on System Load, CPU and Memory Usage.
  • WARNING! snapshotting all of your DNS Servers at the same time will result in no Name Resolution on the network. This will cause connection errors during backups using NFS shares if no other DNS source is in place.
  • WARNING! if multi-flow is used, we suggest to start with 3 flows and increase as your environment allows.
  • The guest hosting the vStorage Agent must be omitted from the backup job as it is not possible to backup a Virtual Machine hosting the vStorage Agent while backing up other VMs. 
backups.us.arkeia.com!vStorage/192.168.5.201/Arkeia Appliance         Flow = 1
backups.us.arkeia.com!vStorage/192.168.5.201/Windows 2003 Server      Flow = 2
backups.us.arkeia.com!vStorage/192.168.5.201/CentOS 5.3               Flow = 3
backups.us.arkeia.com!vStorage/192.168.5.201/Solaris 10 x86           Flow = 1
backups.us.arkeia.com!vStorage/192.168.5.202/Web Apps                 Flow = 2
backups.us.arkeia.com!vStorage/192.168.5.202/Exchange 2007            Flow = 3
backups.us.arkeia.com!vStorage/192.168.5.202/RHEL 5.4                 Flow = 1
backups.us.arkeia.com!vStorage/192.168.5.202/Sharepoint Server        Flow = 2

Misc. vCenter Agent Notes

vMotion

The Arkeia vCenter agent supports VMware's "vMotion.

vMotion moves a virtual machine from one host to another host within a vCenter. The Arkeia vStorage/vCenter agent backs up a virtual machine from a vCenter regardless which host is running it and regardless which datastore are used for this VM and its disks.

Clustered Fault Tolerant Virtual Machines

The virtual machines in a cluster that use fault tolerance do not support snapshots so the backup of such information is not possible.

VM MAC Address

The MAC address of a Virtual Ethernet card of a backed up virtual machine is restored.

If the type of the MAC address was "automatic", the vSphere server is allowed to change it, but if the type of the MAC address was "manual", then you could have two virtual machines with the same MAC addresses. 

EXAMPLE
Restore and rename a VM while the original VM still exists.

vApp VM Templates

Templates of Virtual Machines under vAPP do not support snapshots so they cannot be backed up.

Prerequisites

Before installing and using the vStorage Agent, ensure a backup and restore of files from the client machine is successful.

Linux fuse and libfuse Libraries

THE fuse-lib AND fuse LIBRARIES ARE REQUIRED BY THE ARKEIA vStorage Agent on LINUX TO PERFORM A FILE LEVEL RESTORE FROM A LINUX VIRTUAL MACHINE IMAGE BACKUP. 

error: Failed dependencies:
        fuse is needed by arkpvstorage-x.x.x-x.x
        fuse-libs is needed by arkpvstorage-x.x.x-x.x

Check your environment for the presence of the "fuse" and "libfuse" packages. 

rpm -qa | grep fuse
fuse-2.7.4-8.el5
fuse-libs-2.7.4-8.el5

ldconfig  -p | grep fuse
libfuse.so.2 (libc6,x86-64) => /lib64/libfuse.so.2
libfuse.so.2 (libc6,x86-64) => /usr/lib64/libfuse.so.2
libfuse.so.2 (libc6) => /lib/libfuse.so.2

Install the fuse-lib and fuse libraries in your environment as required.

If you do require "File Level Restore from a Virtual Machine Image Backup on Linux" then you can force install the vStorage Package without dependencies.

VMware vSphere License

VMware requires the activation "vStorage APIs" by the installed vSphere licenses.

Arkeia vStorage License

vStorage License Note
One Arkeia vStorage License is required for each ESX host to be backed up at the vStorage API level. 

Example
If you have ten ESX hosts, and you only want to backup 5 ESX hosts individually, 
then you need five vStorage Licenses from Arkeia.

vCenter License Note

When using the vCenter path, you will need the quantity of vStorage Licenses of Arkeia to match the quantity of Hypervisors registered to vCenter. 

Example
If you have ten ESX hosts registered to vCenter, and you want to backup using the vCenter path, then
you need ten vStorage Licenses from Arkeia.

The vStorage feature of Arkeia requires a separate license.

Install the license on the backup server 

Configure > Licenses

Click "Add A License"

Enter the license information.

Click "Create"


Log out of the Web Interface and log back in or click on the license to activate it.

If you receive the error message "Illegal Key Code", ensure there are no white spaces before and after each license parameter and click "Create" again to enter the license.

Client Connection

Before installing the vStorage Agent, validate client connection by ensuring a backup and restore is successful to the client machine.

Adding A Client

Go to How To Add A Client to start registering clients to the backup server.

Client Connection Troubleshooting

If you are having trouble connecting to a client machine, please check the Public Knowledge Base for the Client Connection and Network Navigator FAQ.

Software Package Version

Before installing the vStorage Agent package, ensure the Arkeia Agent is running the same software version.
Upgrade the Arkeia Agent if the vStorage package is a newer release version. 

MS WINDOWS:

Open a DOS prompt and execute the following command:

C:\Program Files\Arkeia\ANB\bin\arkeiad.exe --version

LINUX and UNIX

Open a command prompt and execute the following command as super user:

/opt/arkeia/bin/arkeiad --version

IMPORTANT: The Arkeia Agent and it's options must be of the same software version.

VMware vStorage Agent Installation

vStorage Agent Planning

Client As Media Server

SAN Storage

Arkeia recommends installing the vStorage agent on an Arkeia Client / Media Server that is directly connected to the SAN.
When used with the Arkeia SSO and/or RSO Option, the data remains on the SAN (LAN Free Backup) and only the meta-data is sent to the backup server.
The SAN (LAN-Free) backups will provide the best performance.

LAN Storage

If the Arkeia Client / Media Server is not connected to the SAN, then the SAN Transport (LAN FREE backup) method is not used.
The NBD / NBDSSL (LAN) data transport method is used with data transfer occurring between the Media Server/vStorage API to the locally attached Media Server storage devices.
This backup method minimizes LAN traffic.

Client NO Media Server

SAN Connected

If the client machine is NOT a Media Server, but has a SAN connection, then the vStorage Agent can be installed on the client. The SAN transport method is used between the Client and the vStorage API, but the backup data is sent from the Client to the backup server storage media.
This backup method minimizes LAN traffic.

LAN Connected

The Arkeia vStorage can be installed on a local LAN client machine, however the NBD / NBDSSL (LAN) data transport method is used.
In this configuration, the data is transferred from the vStorage API over the local LAN and then transferred to the backup server on the same LAN.
This backup method equates to a higher local LAN traffic than the SAN transport methods and is NOT RECOMMENDED.

ESX Host Backup

Arkeia supports the vStorage Agent installed on an Arkeia Client inside a Guest Virtual machine. This would be the equivalent of an "ESX Host" level backup.

The guest hosting the vStorage Agent must be omitted from the backup job as it is not possible to backup a Virtual Machine hosting the vStorage Agent while backing up other VMs.

The HOTADD Transport Mode is used when the vStorage Agent is installed on a Client that is hosted in a VM and the VM is used to process vStorage data from the same ESX/ESXi Server. The HOTADD feature of the vStorage API allows the vStorage Client VM to "hot add" the backup images of virtual disk backups which are seen as local disk to the VM hosting the vStorage Agent. The vStorage VM's CPU and I/O is used to handle the backup resource which is "equivalent" to having an agent installed at the host level.

This method works for both SAN and LAN based environments.

In the SAN Environment, the vStorage Proxy is hosted as a Virtual Machine which registers as normal Arkeia Client on the backup server.
The client (vStorage Proxy Virtual Machine) is then promoted to Media Server Status. If the Tape Drive is attached to the SAN, it can then be Shared with any Arkeia Media Server on the SAN. Once the Tape Drive is Shared with the vStorage Proxy, the vStorage Proxy can then access the Drive for a LAN Free HOTADD vStorage Backup. If the backup is to DiskStorage, the vStorage Proxy must have access to write backup data to the storage. Normally this can be done by mounting the storage LUN to the vStorage Proxy Node.

Backup Server

SAN

Arkeia recommends installing the vStorage Agent on a Backup Server when the Backup Server is located on the SAN.
When used with the Arkeia SSO Option, the data remains on the SAN (LAN Free Backup) and only the meta-data is sent to the backup server.
The SAN (LAN-Free) backups will provide the best performance.

LAN

If the backup server is not connected to the SAN, then the SAN Transport (LAN FREE backup) method is not used.
The NBD / NBDSSL (LAN) data transport method is used with data transfer occurring between the Backup Server/vStorage API to the locally attached backup devices.

This type of backup method (vStorage on the Backup Server) is recommended over (vStorage on a LAN based client) although the backup of vStorage will be seen as a "local" backup on the backup server.

Download Arkeia Software

Go to Arkeia Downloads to obtain the required Arkeia Packages. 

arkpvstorage*-x.x.x

Software Installation

THE fuse-lib AND fuse LIBRARIES ARE REQUIRED BY THE ARKEIA vStorage Agent on LINUX TO PERFORM A FILE LEVEL RESTORE FROM A LINUX VIRTUAL MACHINE IMAGE BACKUP. If you do not plan on using the File Level Restore from a vMware Image Backup, then you can use "force" and "no dependency" options of your preferred installer. 

EXAMPLES
rpm -Uvh --force --nodeps

Install the vStorage Agent on the client machine that will be used to manage the VMware vStorage backups.

yum Installation

yum install ./arkpvstorage*-x.x.x.i386.rpm

.rpm Installation

rpm -Uvh arkpvstorage*-x.x.x.i386.rpm

.tar.gz Installation

tar -zxvf arkpvstorage-x.x.x.tar.gz
cd arkpvstorage*-x.x.x
./install

.zip Installation (Windows)

Unzip and Extract the files to a temporary directory.
Click on "setup.exe" to start the Install Shield process

SElinux

If SElinux is enabled, change the security context of files installed by the arkpvstorage package. 

chcon -t texrel_shlib_t /opt/arkeia/lib/arkpvstorage.so
find /opt/arkeia/lib/vstorage -name \*.so | xargs chcon -t texrel_shlib_t

Adding a VMware / vCenter Server

Configure > VMware VM Servers

Click on "Add A New Server"

Enter the login information for the new ESX/ESXi or vCenter server.

* Hostname or IP address
* User name	
* Password 	

Select the "Node" (Arkeia Client) that has the Arkeia "vStorage" Agent installed or the Arkeia Virtual vStorage Appliance
from the Drop Down list

Click the red plus sign + to add the node into the Arkeia Configuration

Click on "Advanced Option" to specify the port to connect  (Default = 443)

Click "Create"

The server will be added to your Arkeia Configuration, however the connection to the server may not be successful. 

Verify server connectivity detailed in the real time message box.

FAILED CONNECTION
A failed connection will be logged in the real time message window at the bottom of the WebUI.
You will not see any information about your ESX hosts in the Arkeia Information boxes.

SUCCESSFUL CONNECTION
A successful connection will be logged in the real time message window at the bottom of the WebUI.
The ESX host information will be populate upon a successful connection.

Managing A Server

Modify A Server

Configure > VMware VM Servers

Select a Server to modify

Click on "Modify"

Modify the server as required by your environment

Click "Update" to save the changes

Verify server connectivity detailed in the real time message box.

SUCCESSFUL CONNECTION

Change A Password

Configure > VMware VM Servers

Select a Server to modify

Click "Change Password"

Enter and Verify the new password

Click "Update"

Verify Server connectivity detailed in the real time message box.

SUCCESSFUL CONNECTION

vCenter/vStorage Backup Configuration

Create A Savepack

  • Please refer to the Savepack Guide for more details about Savepack options.

Image Level Full Backup (Total Only)

A savepack set WITHOUT the CBT (Change Block Tracking Option) is valid for performing a Full Image Level Backup. 

Configure > What To Backup

Click on "Add A New Savepack"

Select and click "VMware vSphere options" to modify any options required for your environment or accept the default selections.

* Use change block tracking where available:  (default = unchecked)
* Quiesce Guest File System:                  (default = checked)
* Transport mode priority list: 

  SAN - transfer the data over the SAN
  HOTADD - the agent on a VM gets data from a shared storage
  NBD - transfer the data over the network
  NBDSSL - encrypt and transfer the data over the network

Click "Create"

Image Level CBT Backup (Thin-Full, Differential, Incremental)

A savepack set with the CBT (Change Block Tracking Option) will is valid for performing a:

Create an Arkeia Savepack to backup the VMWare Server using (CBT) Change Block Tracking. 

Configure > What To Backup

Click "Add A New Savepack"

Select and click "VMware vSphere options" to modify any options required for your environment or accept the default selections.

Enable CBT (Change Block Tracking)

Enabling CBT will at the Savepack Level will:
* perform a Thin-Full backup if the backup option is set to Total
* perform an Incremental backup if the backup option is set to Incremental
* perform a Differential backup is the backup option is set to Differential

Click "Create"

Backup All VMware Servers

The Savepack configuration is ONLY valid using vCenter or when there is a single VMWare Server configured.
The guest hosting the vStorage Agent must be omitted from the backup job as it is not possible to backup a Virtual Machine hosting the vStorage Agent while backing up other VMs. 

 Backup > What To Backup

Select a Savepack

Click "Browse Trees"

Click and Expand the Arkeia Client where vStorage Agent was installed

Select the "vStorage Agent" icon

Click "Update"

Backup A Specific VMware Server

 Backup > What To Backup

Select a Savepack

Click "Browse Trees"

Click and Expand the Arkeia Client where vStorage Agent was installed

Click and Expand the "vStorage Agent" icon

Select the the Server to backup
The guest hosting the vStorage Agent must be omitted from the backup job as it is not possible to backup a Virtual Machine hosting the vStorage Agent while backing up other VMs.

Click "Update"

Backup Specific Virtual Machines

 Backup > What To Backup

Select a Savepack

Click "Browse Trees"

Click and Expand the Arkeia Client where vStorage Agent was installed

Click and Expand the "vStorage Agent" icon

Click and Expand the "Vmware Server" icon
The guest hosting the vStorage Agent must be omitted from the backup job as it is not possible to backup a Virtual Machine hosting the vStorage Agent while backing up other VMs.

Select Virtual Machine(s) to backup

Click "Update"

Restoration

Virtual Machine Image Level Restore

The Arkeia vStorage Agent supports the following Image Level restore features.

Image Level Restore Features

  • Restore the entire virtual machine
  • Restore a single or multiple virtual machines at once
  • Restore the Virtual Machine and selected disk
  • Restore ONLY the selected disk of a virtual machine backup
  • Restore by a different node than the one which performed the backup
  • Restore to a different hypervisor or vCenter
  • Restore from a hypervisor backup to a vCenter node
  • Restore from a ESX3 backup to vSphere 4 server
  • Restore and rename the virtual machine
  • Restore to a different datacenter or a different Folder (if restored to a vCenter)

Image Level Restore Notes

  • If a disk was not selected during a backup or if the disk was in a mode that DOES NOT support snaphots, it will not show up in the restoration screen.
  • The vCenter agent supports restoring some or all disk from a virtual machine backup.
  • If a selected hard disks is not restored, the restored hard disks of a virtual machine may have their name changed. In this case, the restoration reports a message for every disk name change in the Restoration Logs.
  • When several virtual machines are to be restored, each virtual machine is restored one after the other.
  • When the selected backup to restore is full or a full-thin backup, the restoration is fast because it has to read the data from only one backup source.
  • When the selected backup to restore is an incremental or a differential backup, the virtual machine configuration used to create the restored VM is the one from the selected backup. Once the virtual machine is created, for every VM's disk, starting from the selected backup, all backups are replayed (newer to older) until an older full or full-thin backup is reached.
  • The Arkeia Restoration process keeps the virtual disk opened as long as there is data to restore. Therefore a power ON of this VM from the vSphere client will not disrupt the restoration of the disks contents.

Image Level Restore Operation

Restore Screen

Restore

Select "Restore VMware vStorage"

Click "Next"

Click on the + to expand trees
Any gray shaded boxes are not selectable for restore.

Select a Virtual Machine

Select a Virtual Machine to Restore

Click "Next"

Use the drop down menu to select the backup time to restore from
 By default, all disk available for restore are selected

Choose the Default "Image Level Restore"

Click "Next"

Global Options

Apply the required global options to the restoration job

Select "power on virtual machine after restoration" if you want this VM powered on. If not, do not check this option.

Apply the required overwrite policy as needed by selecting one of the options from the drown down list.

The supported overwrite policies are:

* if VM exists, then do not restore (default)
* if VM exists and not running, then overwrite
* if VM exists and is running, then overwrite

Restore Destination

IMPORTANT


Select a VMware Server

Specify the virtual machine restore destination

Use the ... / browse feature and select the destination VMware Server

* select the source node to restore to the original location
* select a different node to restore to a different location

Click the blue dotted icon to the far right of "Location" to access the Browser

Expand the node hosting the vStorage Agent that will be used for the restore process

Select the VMware Server to restore the Virtual Machine to

Click "Validate"

Select A Data Store

Click the blue dotted icon to the far right of "Data Store" or a "Resource Pool" to access the Browser

Select a data store from the list

Click "Validate"

Virtual Machine Naming

If you are restoring a Virtual Machine to the original destination and using the same Virtual Machine name,
then accept the existing options of the Virtual machine itself.

If you are renaming the Virtual Machine, or restoring to a different location, then expand the Virtual Machine
Options and set the values required for your environment.

Click "Start Restoration"

File Level Restore From Virtual Machine Backup

File Level Restore

Arkeia's vStorage Agent supports file level restores from Virtual Machine backups on Linux and Windows Operating systems supported by VMware. During the restore process, the user can provide a valid Source and Destination file path to initiate a file level restore. If a the Source and Destination paths are unknown, Arkeia provides a File Level Browser than can be used to select the correct file to restore and the destination path from the restored/mounted VMware Image.

When a File Level restore is started, Arkeia will restore and mount the VM Image to the user defined staging location within the Virtual Environment. Once the Image is restored, the file level selection of restoration can occur.

  • File Level restores from Virtual Machine backups are supported on Linux and Windows systems supported by Vmware.
  • The Arkeia Backup Server, WebUI and vStorage Agent must be v8.2.14 or higher.
  • The File Level restore is backwards compatible to older Arkeia Clients.
  • Indexing of files inside the VM is accomplish when performing a file level restore and not at the time of backup.
  • An Arkeia Agent must be installed inside of the Destination client machine which can be a Virtual or Physical machine.
  • If the source path is unknown, Arkeia provides a browser to select the files to restore from the mounted Virtual Machine Imag
  • If a valid source and destination file path have been selected, the image of the VM is restored to the machine where the Vstorage Agent is running. The image is then mounted to the local file system and the files are extracted and sent to the destination machine.
  • THE fuse-lib AND fuse LIBRARIES ARE REQUIRED BY THE ARKEIA vStorage Agent on LINUX TO PERFORM A FILE LEVEL RESTORE FROM A LINUX VIRTUAL MACHINE IMAGE BACKUP.

File Level Restore Notes

File Level restores from Virtual Machine backups are supported on Linux and Windows systems supported by Vmware.

Linux Operating System

File Level restores from a Linux Virtual Machine backup should be restored using a Linux vStorage Agent for best results.
The Linux vStorage Agent must be hosted on a Linux environment supported by VMware or an Arkeia Virtual vStorage Appliance which is hosted on CentOS 5.4 (RHEL5).

  • ext3 and ext4 file systems are fully supported
  • VMware vStorage DOES NOT support soft-RAID configurations

Arkeia's vStorage Agent supports the restore of files from VM backups to Linux LVM partitions by using loopback devices to mount rhe LVM logical volumes of the restored Virtual Machine.

  • Only the MBR (or DOS) type of LVM partitions are supported
  • A maximum of 8 "physical volumes" of LVM can be file-level-restored at the same time based on the kernel parameter "max_loop".
  • LVM GPT partitions are NOT supported
  • unpartitioned LVM devices used as disk "instead of disk partitions" are NOT supported

Windows Operating System

File Level restores from a Windows Virtual Machine backup should be restored using a VMwware supported Windows Operating System hosting the Arkeia vStorage Agent. The Arkeia Windows vStorage Agent must be installed on a Windows environment supported by VMware.

  • FAT, FAT16, FAT32 and NTFS file systems are supported
  • MBR partitions are supported
  • VMware vStorage DOES NOT support GPT partitions
  • Simple volumes with either basic disks or dynamic disks are supported
  • Mirrored volumes are supported
  • Stripped volumes are supported
  • Spanned volumes are supported
  • Software RAID 5 volumes are NOT SUPPORTED by VMware vStorage

File Level Restore Prerequisites

Arkeia Client Agent

A File Level Restore from a Virtual Machine backup requires the presence of an Arkeia Agent inside of the destination operating system.
The destination machine can be a physical or virtual machine (supported by VMware) hosting the Arkeia Client Software.

  • Please refer to the Adding Clients Guide for more details and the correct procedure for adding and validating client machines.

IMPORTANT ARKEIA CLIENT NOTE:
When Arkeia Software is installed on a client machine, it may register itself to the backup server and appear in the client list.
However, the added client will not be counted against your Arkeia Client License limit unless the added client machine is being backed up.

Since the client is NOT USED FOR BACKUPS, it is considered in "Arkeia Agent Restore Mode" because it will only be used to restore data.
In the example listed below, some client entries are only used for Restoration Operations and are not counted against my client license limit. 

Configure > Clients

Arkeia vStorage Agent

The restore of a file from a Linux Virtual Machine backup requires a Linux vStorage Agent.
The restore of a file from a Windows Virtual Machine backup requires a Windows vStorage Agent.

IMPORTANT ARKEIA VSTORAGE NOTE:
Arkeia Network Backup allows multiple vStorage Agent installations and connections to the VMware Servers added in the Web Interface.
The extra added vStorage Agent will not count against your Arkeia vStorage Agent License limit unless you attempt to backup the VMware environments using this new path.

In the example below, there are three Arkeia Nodes hosting the vStorage Agent associated to my VMware Server. 

hyper-v.us.arkeia.com                 (Windows 2008 R2 Server)                NOT counted against vStorage license
vstorage-appliance.us.arkeia.com      (Arkeia vStorage Virtual Appliance)     NOT counted against vStorage license
sbrown.us.arkeia.com                  (RHEL 5.5 Backup Server)                IS counted against vStorage license

The backup of the Virtual Machines is accomplished using the path of "sbrown.us.arkeia.com!vStorage:/192.168.5.141/" which is the only vStorage Agent path counted against the Arkeia Licenses. The node names associated with the VMware Server are using for Linux and Windows File level restorations. 

Nodes > VMware Servers

File Level Restore From Virtual Machine Backup Operation

Arkeia Agent

An Arkeia Agent must be installed inside of the Destination client machine which can be a Virtual or Physical machine.

Download and install the Linux or Windows Arkeia Agent on the restore destination machine as needed.

  • Please refer to the Adding Clients Guide for more details and the correct procedure for adding and validating client machines.

Linux fuse and fuse-libs Libraries

The vStorage Agent on supported VMWare Linux platforms require libfuse.so libraries to mount the restored VMware Images. 

Ensure that you have the libfuse.so libraries installed on your system.

locate fuse
/usr/lib64/libfuse.so.2
/usr/lib64/libfuse.so.2.7.4

vStorage Agent

Download and install a Linux or Windows vStorage Agent or the Arkeia vStorage Virtual Appliance if you are currently using a Windows Operating System to host the Arkeia vStorage Agent.

vStorage Agent Temp Directory

The File Level Restoration from a Virtual Machine backup requires mounting the VM Image to a temporary directory on the machine hosting the Arkeia vStorage Agent.
The directory must have enough available disk space to mount the entire restored Virtual Machine Image.If no path is specified, the Arkeia Installation directory is used.

The "ARKPVSTORAGE_RST_TEMPDIR" path must be large enough to host all Virtual Machine Disk selected for restoration.
Failure to have sufficient disk space will result in a failed restore attempt.

The vStorage Temporary Restore Path can be modified using the Arkeia Web Interface or using a text editor.

Web Interface Configuration

Configure > Clients

Select the client hosting the vStorage Agent

Click on "Plugin Configuration" for the client selected

Select the "vStorage Plugin"

Modify the path as required for your environment

Click "Apply" to activate the changes

Command Line Configuration

LINUX
Open a Linux console as super user and edit the "arkpvstorage-rst.prf" file as needed for your environment. 

vi /opt/arkeia/arkeiad/arkpvstorage-rst.prf

ARKPVSTORAGE_RST_TEMPDIR    "/tmp"

WINDOWS
Open the "arkpvstorage-rst.prf" file using Wordpad or DOS and edit as needed for your environment. 

C:\Program Files\Arkeia\ANB\Arkeiad\arkpvstorage-rst.prf

ARKPVSTORAGE_RST_TEMPDIR    "D:\restores"

Technical Details

During a File Level restore process, you can see the Virtual Machine image and disk being mounted to your defined temp directory. 

[root@sbrown ]# ls -latr /tmp/2f56-1HMAOz/
total 28
-rw-rw-rw-  1 root root    30 Feb 23 08:22 vddk.conf.XeHfDj
drwxrwxrwx 23 root root 12288 Feb 23 08:22 ..
drwx------  3 root root  4096 Feb 23 08:22 Arkeia vStorage Virtual Appliance
drwx------  3 root root  4096 Feb 23 08:22 .

[root@sbrown ]# ls -latr /tmp/2f56-1HMAOz/Arkeia\ vStorage\ Virtual\ Appliance/
total 12
drwx------ 3 root root 4096 Feb 23 08:22 ..
drwx------ 3 root root 4096 Feb 23 08:22 .
drwx------ 3 root root 4096 Feb 23 08:23 vmdk

[root@sbrown ernie]# ls -latr /tmp/2f56-1HMAOz/Arkeia\ vStorage\ Virtual\ Appliance/vmdk/
total 954716
drwx------ 3 root root      4096 Feb 23 08:22 ..
-rw------- 1 root root    851968 Feb 23 08:23 Hard disk 2.vmdk
drwxrwxrwx 2 root root      4096 Feb 23 08:23 Hard disk 1.vmdk.lck
drwx------ 3 root root      4096 Feb 23 08:23 .
-rw------- 1 root root 975896576 Feb 23 08:25 Hard disk 1.vmdk

Restore Screen

Restore

Select "Restore VMware vStorage"

Click "Next"

Click on the + to expand trees
Any gray shaded boxes are not selectable for restore.

Select A Virtual Machine

Select the Virtual Machine to Restore from

Change the Restore Selection from the default of "Image Level Restore" to "File Level Restore"

Click "Next"

Select A Virtual Disk

Use the Drop Down menu to select the backup job to restore from.

Select the Disk required for restore

If you know which disk the file to be restored is located on, then you can "unselect" 
the Disk that are not required for this restore operation.

If you DO NOT know which disk the file to be restored is located on, then restoring
all Disk would be the preferred option.

Click "Next"

Global Options

Select a Linux machine running the Arkeia vStorage Agent to restore files from a Linux VM.
Select a Windows machine running the Arkeia vStorage Agent to restore files from a Windows VM. 

Click the blue dotted box icon to open the selection feature

Select the Linux machine hosting the vStorage Agent

Click "Validate" to accept the selection

If you need to change the selection to a different machine hosting the vStorage Agent,
click the blue dotted box icon to browse and select a different machine.

Choose the File Attributes to restore or accept the defaults

Choose the File Ownership, Restore Rights and Email Reporting options or accept the defaults.

Select the File(s) To Restore

Select the "Restoration Destination Policy" to be used for the restore operation.

* Restore full paths (Default)
* Restore relative paths

Known File and Directory Paths

If the Source file or directory paths are known, then you can enter the paths manually.
The restore operation will mount the VM and restore the selected paths.

If you are not aware of the paths, or the paths that you provided where false, the Arkeia Restore job will prompt with a Volume Navigator that will allow you to select the correct source data to restore. 


A typical Volume path to a VM may be as follows:

Linux
/Volume 1/path/to/file
/Volume 2/path/to/file
/Volume 3/path/to/file

Windows
/C/path/to/file
/D/path/to/file
/E/path/to/file
Known Source

In the Linux VM examples below, the known paths are located in "/Volume 2".
Your environment may be different so plan accordingly. 

Entry the first file or directory path to restore

Use the blue plus signs to add more file or directory paths to restore
Known Destination
Click on the blue dotted browse icon to choose a restore destination

Use the Client Browser feature to locate the Destination Client and Restore path.
The Client Browser will list all Arkeia Clients Registered to the backup server.

Use the Browser to select the client and restore path

Click "Validate" to accept the path selected.
Restore Selection Review

Review your File Level Restore operation selection to ensure: 

* A Linux vStorage Agent is used to restore files from a Linux Virtual Machine backup
* A Windows vStorage Agent is used to restore files from a Windows Virtual Machine backup

Click "Start Restoration"

Unknown File and Directory Paths

Unknown Source

If the Source file or directory paths are unknown, then leave the "Path to Restore" field empty.
The restore operation will mount the VM, and provide a Navigator to browse and select the files from the mounted volumes. 

Leave the "Path to Restore" field empty
Unknown Destination

If the destination file or directory paths are unknown, then leave the "Select a Destination" field empty.
The restore operation will mount the VM, and provide a Navigator to select the Source and Destination paths. 

Leave the "Select a Destination" field empty

 Click "Start Restoration" to access the begin the restore process and access the File Navigator.

Starting the Restore process will open up the main restore screen where you can see the job 
restoring the Virtual Machine and mounting the volumes.

WAIT AT THIS SCREEN. THE VOLUME NAVIGATOR WILL BE PROVIDED IN A POPUP WINDOW AFTER THE VOLUMES HAVE BEEN MOUNTED.
Volume Navigator File Selection
Once the Virtual Machine and it's disk have been mounted, use the provided Volume Navigator to select the 
Source file(s) or directories to restore.
If you receive a connection or open navigator error, press the "F5" key to fresh the screen.

Expand the Volume Navigator and select the files and directories required for restore.

Click "Next"

Use the Client Browser to select the destination machine and restore path.

The list will display all Arkeia Clients registered to the backup server even if they are only used in Restore Mode (no being backed up).

Expand the Client Navigator and select the destination machine and restore path.

Click "Continue Restore Job" to continue the restore process

Click "OK" to close out the restore job

Trouble Shooting

You do not have access rights to this file

The backup of VMware Disk can fail with the following message if the disk does not support the backup method.
Please refer to the Data Transport and Disk Backup Support section of this for more details. 

arkeia-vsphere4: my virtual machine: cannot backup disk 'Hard disk 2' while the virtual machine is powered on

Arkeia vStorage Logs

arkpvstorage (31287) arkplug_backup_opendir: Opening '/xx.xx.xx.xx/virtual-machine-name/Hard disk 1'
arkpvstorage (31287) arkpvstorage_bksid_to_changeid: Entering
arkpvstorage (31287) arkpvstorage_bksid_to_changeid [L195]: Normal end
arkpvstorage (31287) vmsdk_get_references: Entering: vm=virtual-machine-name disk=Hard disk 1

arkpvstorage (31287) arkplug_backup_opendir: Entering (2: No such file or directory)
arkpvstorage (31287) vmsdk_init_jni: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_connect: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_do_snapshot: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_check_task: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_list_vmdisks: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_dump_vmconfig: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_get_references: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_remove_snapshot: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_do_snapshot: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_check_task: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_list_vmdisks: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_dump_vmconfig: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_get_references: Normal end (2: No such file or directory)
arkpvstorage (31287) vmsdk_remove_snapshot: Normal end (2: No such file or directory)

arkpvstorage (31287) arkpvstorage_vddk_connect: Normal end
arkpvstorage (31287) arkpvstorage_open_disk: Entering: [virtual-machine-name:storage1]virtual-machine-name/virtual-machine-name.vmdk
arkpvstorage (31287) arkpvstorage_open_disk [L230]: Bad end
arkpvstorage (31287) libvddk_logerror: You do not have access rights to this file
arkpvstorage (31287) arkplug_backup_opendir [L399]: Bad end
arkpvstorage (31287) arkplug_get_last_error [L229]: Entering

vStorage Agent Restore Fails: DVS error: see faultCause

A Virtual Machine restore with redirection / rename can fail with a "DVS faultCause error" if the restore is done on the same host as the source VM and the source VM is still present and online. 

Example Backup Job:

Start of VMware vStorage restoration job
Starting restoring from the backup of the savepack 'vStorage Backup (09-03-2010 22:00:02)'
[1] backup.us.arkeia.com: Restoring the virtual machine 'Virtual Machine 001'...
[1] backup.us.arkeia.com: Restoring the configuration of 'Virtual Machine 001'...
[1] backup.us.arkeia.com: Failed to restore the configuration of 'Virtual Machine 001'!
[1] backup.us.arkeia.com: Failed to restore the virtual machine 'Virtual Machine 001'!
[1] backup.us.arkeia.com: The restoration failed!
'0 B' restored in '666' seconds (0 B/s)
End of restoration from the backup of the savepack 'vStorage Backup (09-03-2010 22:00:02)'

Example vStorage Agent Logs:

arkpvstorage-rst (15253) vmsdk_logerror [L799]: sdk fault = 79 (2: No such file or directory)
arkpvstorage-rst (15253) vmsdk_logerror: reason = DVS error: see faultCause
arkpvstorage-rst (15253) vmsdk_logerror: str[0] = sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
arkpvstorage-rst (15253) vmsdk_logerror: str[1] = sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
arkpvstorage-rst (15253) vmsdk_logerror: str[2] = sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
arkpvstorage-rst (15253) vmsdk_logerror: str[3] = java.lang.reflect.Constructor.newInstance(Unknown Source)
arkpvstorage-rst (15253) vmsdk_logerror: str[4] = java.lang.Class.newInstance0(Unknown Source)
arkpvstorage-rst (15253) vmsdk_logerror: str[5] = java.lang.Class.newInstance(Unknown Source)

The "faultCase" property is returned as a vMware System Error from the Distributed Virtual Switch (DVS) environment.

When the vStorage Agent performs a backup of a Virtual Machine, it backs up the name of the network adapter to which is it connected.(example: "VM Network 1"). When performing a restore, the vStorage Agent sets the same name even if the network does not exist in the vSphere Configuration.

For a network adapter that is attached to a DVS, the vStorage Agent will backup and restore:

  • The UUID of the switch
  • The key of the port or the key of portgroup

When restoring with redirection/rename, the source Virtual Machine Ethernet adapter(s) could be attached to a port of a DVS. This would cause the restore process to fail because the newly named Virtual Machine will attempt to attach to the same port as the source VM. Since the port is occupied for the original VM, the restore process fails.

SOLUTION:

Create a temporary port group and attach the original Virtual Machine.
Start the restoration again which will allow the restored/renamed VM to attach to the original DVS and port configuration.

Cannot create a quiesced snapshot because the create snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine

The following error can occur when backup up a guest (Virtual Machine) using the vStorage Agent, when the guest being backed up is hosting the vStorage Agent. 

[1] arkeia.vstorage: Cannot browse '/192.168.5.144/Arkeia Server/Hard disk 1': 'Failed to create a snapshot of Arkeia Server: 
Cannot create a quiesced snapshot because the create snapshot operation exceeded the time limit for holding off I/O in the frozen virtual machine.'
[1] Backup of "arkeia.vstorage!vStorage:/192.168.5.144/Arkeia Server/Hard disk 1" partially OK, "1" files, "1" MB, "1" seconds, "60" MB/mn, "1" errors

The guest hosting the vStorage Agent must be omitted from the backup job as it is not possible to backup a Virtual Machine hosting the vStorage Agent while backing up other VMs.

VMware CBT Backs Up The Entire Disk

This is a known issue on the VMware vStorage API Side.

ISSUE:

The backup using CBT fails on a VM disk that has been backed up or shapshotted, and has had CBT activated by another utility.

SOLUTION:

The solution is to reset CBT on the Virtual Machine Guest.

OPTIONS:

VMare Communities provides a script that can reset CBT for all VMs.
http://communities.vmware.com/docs/DOC-11642

Or the resetting can be done manually at each VM. 

1) stop your VM
2) delete all VM snapshots that you have on disk 
3) open VMware vSphere Client
       * right-click the VM
       * choose Edit Settings -> Options tab
       * select General
       * click Configuration Parameters
       * set ALL ENTRIES with ‘ctkEnabled’ substring to FALSE including disk entries
4) power on the VM 
5) start a total Arkeia Backup using CBT

Connection Errors

A connection error may occur during the backup of vMware if there is no data transfer within 15 minutes. 

2009/09/23 09:00:08 [1] Backing up vcenter.us.arkeia.com
2009/09/23 09:15:08 **** Connection error with vcenter.us.arkeia.com (pid=20808) ****
2009/09/23 09:15:09 **** Recover timedout with vcenter.us.arkeia.com (pid=20808) ****
2009/09/23 09:15:09 **** Can't recover connection with vcenter.us.arkeia.com (pid=20808) ****
2009/09/23 09:15:09 [1] Backup of "vcenter.us.arkeia.com" not OK, "0" files, "1" MB, "1" seconds, "60" MB/mn, "0" errors, error code = "3"

If the Arkeia Network Layer Protocol (NLP) doesn't receive any data for 15 minutes it may report a connection error and start a recovery procedure for an additional FLOW_TIMEOUT delay (15 minutes by default).

Add the following parameter to the server.prf file to extend the flow time out. 

vi /opt/arkeia/server/server.prf

FLOW_TIMEOUT "3600"

# default   = 15 minutes
# 3600 sec  = 1 hour
# 7200 sec  = 2 hours
# 10800 sec = 3 hours
# 14400 sec = 4 hours
Retrieved from "http://wiki.arkeia.com/mediawiki/index.php/Network_Backup_Version_9.1_VMware_vStorage/vCenter_Guide"
Personal tools