Role | Operations | Typical Service Group |
Backup Administrator | Can perform all administrative activities in Veeam Backup & Replication | Veeam_BaR_Administrator |
Backup Operator | Can start and stop existing jobs and perform restore operations | Veeam_BaR_Operator |
Backup Viewer | Has the “read-only” access to Veeam Backup & Replication – can view existing and performed jobs and review the job session details | Veeam_BaR_Viewer |
Restore Operator | Can perform restore operations using existing backups and replicas | Veeam_BaR_Restorer |
Once this is done, we then look at the permissions that this role requires inside of VMware; after all, this is what we are working to back up or report upon. The list of permissions for creating backups on Veeam Backup & Replication v5.0.2 is found in the table below:
Privilege Level | vStorage API Virtual Appliance mode | vStorage API Network mode | vStorage API SAN mode |
Global | Log event | Log event | Log event |
Datastore | Low-level file operations | Low-level file operations | Low-level file operations |
Virtual Machine state | Create SnapshotRemove Snapshot | Create SnapshotRemove Snapshot | Create SnapshotRemove Snapshot |
Virtual Machine configuration | Disk change trackingChange resource Add existing disk Remove disk | Disk change tracking | Disk change trackingDisk lease |
Virtual Machine provisioning | Allow read-only disk access | Allow read-only disk access | Allow read-only disk access |
The interesting things to really note here are around the different modes that Veeam is able to back up over and subsequently, the ability to tighten the permissions required to the specific environment. Virtual Appliance mode requires the add existing disk, remove disk and change resource permissions because Veeam uses the VMware HotAdd functionality to attach the source drive to the Veeam VM to transfer the data to the target storage, and has been doing so since v3.0 of Veeam Backup & Replication. Disk lease in the SAN mode of Veeam Backup and Replication is required, as Veeam physically takes management of the VMFS volume from the ESX(i) environment for the period that it copies the data over the physical storage infrastructure. Once we’ve created the service account with the appropriate permissions, it often turns to firewalls and port numbers, so we examine the communication ports that Veeam operates across. Ports 9392, 9393 and 9394 are used for Backup and Replication Services, the backup catalog and the Veeam Enterprise Management console respectively. These ports are all standard TCP ports and can be amended to fit into a corporate firewall infrastructure. It is definitely worth checking with the security team that these ports are open and available for use without causing conflicts and having them added as trusted ports in the port database. In today’s market, VSS-enabled backups are expected, and application-aware backups are certainly at the top of the desirable list as more and more organizations need to perform object-specific recoveries into complex applications. I’ve always found DBA’s to be slightly touchy about backups, since agents can have unintended effects on the databases that they are used on, especially if they are developed in house, and additional permissions are required for the agent to be able to communicate with its relevant backup server. Veeam’s own VSS implementation for backups is innovative, using a transient piece of code to initiate a VSS flush within the application. This is done using the application’s own VSS engine with the framework provided by the operating system. The conversation soon turns to the breadth of customization of the VSS interaction on a machine basis. The long and the short of this is that a lot of secure environments will not provision an over-arching, domain-wide VSS service account, but rather rely on machine-specific VSS credentials to perform a flush. Veeam gives you the ability to set individual VSS credentials per machine within a job, ensuring that the appropriate level of permissions are maintained on a set once basis.
Privilege Level | Required Permission |
Global | Log Event |
Datastore | Low-Level File OperationRemove File Browse Datastore |
Host Configuration | Network ConfigurationStorage Partition Configuration |
Network | Assign Network |
Virtual Machine Interaction | Power OnPower Off |
Virtual Machine Configuration | AdvancedAdd or Remove Device |
Virtual Machine Inventory | RemoveRegister Unregister |
Resource | Assign Virtual MachineCreate Resource Pool Remove Resource Pool |
Folder | Create FolderDelete Folder |
dvPort Group | CreateDelete |
The final piece of the POC was a puzzling one, which admittedly took me a couple of hours to resolve. Since security was key to the environment, all extraneous ports had been removed from the virtual switches inside the ESX(i) hosts to ensure that no unnecessary traffic or openings were left exploitable. This included the vmkernel port being removed from all but the vMotion VLAN, which precludes an NFS volume from being mounted on a host, and therefore prevents Instant VM Recovery being performed. So just note to have a quick check to see that the vmkernel port is present on the VeeamV if you are planning to use the feature!