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
- Veeam KB 2273 – Configuration for VMware vSAN
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..?
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.