Veeam Backup v10 on vSAN 7.0

Create Linux Repository

We now have a Veeam server and four proxies in place, but we need a backup target too. That’s the backup repository.

Warning! We’re doing something foolish here. Building a backup repository within the workload cluster is not the smartest idea. In this special case it’s legitimate because it’s a POC and we’re using it just for demonstration purposes. Please, don’t do that in production !

Every VMCE

Let’s imagine we have a Linux bare metal server somewhere outside the cluster. To make use of XFS fast clone functionality we need to make sure the package is installed. We can check with:

apt list --installed | grep -i xfs
xfsprogs/focal,now 5.3.0-1ubuntu2 amd64 [installed,automatic]

We’re ready to go. I’ve added a second hard disk to the VM (sdb) with 500 GB (thin). Let me point that out again: Read the warning above! Of course it is not a good idea to keep your backup repository inside your vSAN datastore. But for demonstration purposes as POC it is acceptable. I will not store backups of any value in there.

Let’s list our current block devices.

sudo lsblk
veeam@repo01:/$ sudo lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 55M 1 loop /snap/core18/1754
loop1 7:1 0 55M 1 loop /snap/core18/1705
loop2 7:2 0 27.1M 1 loop /snap/snapd/7264
loop3 7:3 0 69M 1 loop /snap/lxd/14804
loop4 7:4 0 69.2M 1 loop /snap/lxd/14954
sda 8:0 0 40G 0 disk
├─sda1 8:1 0 1M 0 part
└─sda2 8:2 0 40G 0 part /
sdb 8:16 0 500G 0 disk
sr0 11:0 1 1024M 0 rom

We can see the second disk device as sdb. We’re going to create one partition on disk device sdb and format partition sdb1 with XFS

sudo fdisk /dev/sdb

Fdisk will ask you a few questions. Enter shortcodes p – n – p – 1 – return – w. Then we’ll have a partition sdb1 on device sdb. We’re going to format it with the XFS file system.

mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb1

Now the partition sdb1 is formatted as XFS. Next step is to create a mountpoint for the partition.

sudo mkdir /backup

To mount it once (it will be lost after reboot) we can use the mount command.

sudo mount /dev/sdb1 /backup/

Update /etc/fstab

If we want to have a permanent mount (yes we do), we must edit fstab. To do so we need to know the UUID of our new partition. First line is the command, second line the result.

sudo blkid /dev/sdb1
/dev/sdb1: UUID="0318cfe3-0be2-4d6a-848f-aa074f5871ed" TYPE="xfs" PARTUUID="b4324d2e-01"

Copy UUID from console and open /etc/fstab in an editor.

sudo nano /etc/fstab

Add a line at the end of fstab. Replace my UUID with yours 😉

UUID=0318cfe3-0be2-4d6a-848f-aa074f5871ed  /backup xfs defaults 1 1

Write fstab and close the editor. Reboot host and test.

df -T

Add repository

That’s the final requirement before we can create backup jobs. We need to add our Linux repository to the Veeam backup infrastructure.

Enter a name of your choice for the repository.

Again, we have to add a new server.

Enter FQDN or IP of the repository server.

Also provide credentials to the Linux repository server. I’m lazy here. I’ve used the same template that I’ve used for the proxies. So I can re-use the credentials.

We now have to tell Veeam where on the repository server we want to store backups. Click on “Browse” to see the root directory on the repository server.

Once we’ve selected the folder (mount point), we can populate information about free space and capacity.

Make sure to check the fast cloning option (red frame).

Links

2 Replies to “Veeam Backup v10 on vSAN 7.0”

  1. If your Linux Repository is on a external PC or even on one of the ESXi hosts, then the Backup Proxy still has to send data over the network? Your picture (on the left) has the proxy magically sending data (green arrows) through thin air to the repository..?

    1. Hi Michael
      Thanks for asking and sorry for not labeling the green arrows. 😉
      First of all: in a production environment the repostitory MUST be on a remote host OUTSIDE the protected cluster. Please see warning on top of page 3.
      Talking about Proxy LAN traffic:
      Of course proxies need do send their backup traffic over a separated VM network segment.
      The point is that we keep our backup traffic away from the vSAN backend. See Veeam KB 2273.
      If you design your vSAN infrastructure properly, then VM portgroups will use a different uplink port than vSAN.
      Yet still there is a chance that we see increased vSAN traffic during backup for some VMs. This can be a result of vSAN cluster properties with a distinct disk object. Veeam cannot predict that.
      Nevertheless a distributed proxy design will minimize the overall load on vSAN backbone during backups.

Leave a Reply

Your email address will not be published. Required fields are marked *