NetBackup™ for VMware Administrator's Guide
- Introduction
- Required tasks: overview
- Configuring RBAC roles for VMware administrators
- Notes and prerequisites
- VMware vSphere privileges
- Managing VMware servers
- About VMware discovery
- Add VMware servers
- Change resource limits for VMware resource types
- Configuring backup policies for VMware
- Backup options on the VMware tab
- Exclude disks tab
- Configuring a VMware Intelligent Policy
- About the Reuse VM selection query results option
- Use Accelerator to back up virtual machines
- Configuring protection plans for VMware
- Malware scan
- Instant access
- Instant rollback
- Continuous data protection
- Backing up virtual machines
- VM recovery
- VMware agentless restore
- Restoring Individual files and folders from VMware backups
- Using NetBackup to back up Cloud Director environments
- Recover VMware Cloud Director virtual machines
- Restore virtual machines with Instant Recovery
- Protecting VMs using hardware snapshots and replication
- Best practices and more information
- Troubleshooting VMware operations
- NetBackup logging for VMware
- Snapshot error encountered (status code 156)
- Appendix A. Configuring services for NFS on Windows
- About configuring services for NFS on Windows 2012 or 2016 (NetBackup for VMware)
- Appendix B. Backups of VMware raw devices (RDM)
Linux VMs and persistent device naming
For Linux VMs without persistent device naming, multiple disk controllers (such as IDE, SCSI, and SATA) may complicate the recovery of individual files. This issue occurs because non-persistent device naming, such as /dev/sda and /dev/sdb, may cause unexpected mount point changes after a restart. If the VM has a SCSI disk and SATA disk, the Backup, Archive, and Restore interface may show incorrect mount points for the VM's files. For example, the files originally under /vol_a might appear under /vol_b when you browse to restore them. The restore is successful, but the restored files may not be in their original directories.
As a workaround, search for the files on the restored VM and move them to the proper locations.
To prevent this issue on Linux VMs with multiple disk controllers, it is recommended a persistent device-naming method for mounting the file systems. When persistent naming is in place, device mounting is consistent and this issue does not occur when you restore files from future backups.
For persistent device naming, you can mount devices by UUIDs. The following is an example of the /etc/fstab
file that contains the devices that are mounted by UUIDs:
UUID=93a21fe4-4c55-4e5a-8124-1e2e1460fece /boot ext4 defaults 1 2 UUID=55a24fe3-4c55-4e6a-8124-1e2e1460fadf /vola ext3 defaults 0 0
Note:
Limit the number of characters for each fstab
entry to 90 on a VMware VM.
To find the device UUIDs, you can use either of the following commands:
blkid
ls -l /dev/disk/by-uuid/
Note:
NetBackup also supports the by-LABEL method for persistent device naming.