Hey there,
we're currently running a HyperV cluster with two Hosts and a simple Proxmox machine in our environment. We're using the Standard Edition of Veeam.
Before we replaced our normal EXT4 NAS with a ZFS based FreeNAS we were simply doing a forward incremental backup to the SMB share. Beside this we're still doing a daily backups on rotating drives.
Our current plan is to use ZFS snapshots to create a history of 2 years of backup files. In Proxmox you simply create a block level snapshot of a vm dataset and zfs-send it over to FreeNAS. Our goal is it to archive the same behavior with our HyperV hosts using Veeam.
The best way would be to have a single .vbk file where Veeam daily commits the block changes of the HyperV VMs into, without any deduplication or compression, so ZFS can simply snapshot the block changes for each day. To restore a backup we simply select a .vbk file from the ZFS Snapshot directory \\NAS-01\Veeam\.zfs\snapshots\date\*.vbk.
But how to create this single .vbk file in Veeam? I think the reverse incremental backups are exactly what we need for this use case. However Veeam still creates some .vbr files and deletes them after a few days. When you would snapshot this .vbr files too, the ZFS snapshots will get bigger and bigger as the time goes on which we would like to prevent. The same would be for Full Backups. Veeam will create a new file and delete the old file which will result in new allocated blocks and the ZFS snapshot will extremely grow. So is it possible to simply write a full backup to the same file, or is it just fine to run reverse incremental backups for a very long time?
Is there a way to disable the creation of .vbr files and to create only a full .vbk backup file where the changes will be commitet into, or even better, automatically move the created .vbr files to a different SMB share or directory (without zfs snapshots enabled)? So we will have the more ransomware-safe ZFS snapshots and also some incremental .vbr files besides our daily offline backups? Is there an official supported way to archive this?
-
- Lurker
- Posts: 2
- Liked: 1 time
- Joined: Apr 12, 2020 12:05 pm
- Contact:
-
- Lurker
- Posts: 2
- Liked: 1 time
- Joined: Apr 12, 2020 12:05 pm
- Contact:
Re: Veeam Backup with ZFS Snapshots
Ok we found out that it is possible to set the retention policy to 1 in reverse incremental mode. With this Veeam will only keep the .vbk file and deletes the vrb file immediately. When ZFS creates a snapshot it only use the space of changed blocks within the .vbk file. So that is absolutely working as expected.
We have enabled the visibility of the .zfs snapshot directory and are now able to simply browse the share to any state of the .vbk file and restore it using Veeam. Because the snapshots are readonly and it's very, very unlikely that Ransomware gain root access to our FreeNAS this method should be Ransomware safe, which a simple normal forward incremental backup laying around on a share is not.
Do any other customers have a similar setup with ZFS as we do? And is this an official supported way, or do you see any risks?
-----
When using reverse incremental it is recommend to periodically run active full backups. However active full backups will create a seperate backup file on the share and may delete the old one afterwards. This will result in new allocated/deleted blocks which will increase the ZFS snapshot size extremely. Is there a way to write the active full to the existing blocks of the .vbk file? What happens if you enable DisableVBKRename https://www.veeam.com/kb1076 and then run an active full? Will it write to the same blocks?
I know that this use case is a thing you would never actually do: overwriting your existing backup. However when using a filesystem which uses block level snapshots this feature would be very handy.
We have enabled the visibility of the .zfs snapshot directory and are now able to simply browse the share to any state of the .vbk file and restore it using Veeam. Because the snapshots are readonly and it's very, very unlikely that Ransomware gain root access to our FreeNAS this method should be Ransomware safe, which a simple normal forward incremental backup laying around on a share is not.
Do any other customers have a similar setup with ZFS as we do? And is this an official supported way, or do you see any risks?
-----
When using reverse incremental it is recommend to periodically run active full backups. However active full backups will create a seperate backup file on the share and may delete the old one afterwards. This will result in new allocated/deleted blocks which will increase the ZFS snapshot size extremely. Is there a way to write the active full to the existing blocks of the .vbk file? What happens if you enable DisableVBKRename https://www.veeam.com/kb1076 and then run an active full? Will it write to the same blocks?
I know that this use case is a thing you would never actually do: overwriting your existing backup. However when using a filesystem which uses block level snapshots this feature would be very handy.
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Jul 27, 2020 3:19 pm
- Contact:
Re: Veeam Backup with ZFS Snapshots
I was looking to do exactly the same as you do. Is it working out for you?
I currently have veeam b&r on windows and most of the backups also on a windows machine but due to those being vulnerable to a host of exploits and microsoft products being microsoft products , pass the hash , bugs , etc ...
I want to protect against ransomware that would have compromised the veeam server and the backup server. So I also have a freenas server I was planning to use. I also thought about how the currrent backups create a full , incrementals and then sometimes synthetic incrementals and how snapshotting this, would result in too much space usage and perhaps weird 'states'.
I did not think about using reverse increments .... I was thinking about an approach much too complicated I think.
I was going to create a Zvol on freenas, use it as a iscsi datastore on an ESXI server and have veeam do replication of my veeams to that esxi server on that freenas datastore, thinking that if those replicas are just offline, they would not consume any cpu/ram resources from that esxi , nor space since they would be sitting on the extra datastore iscsi from freenas.
And than i'd snapshot that Zvol, which would basicly be snapshots of the entire datastore containing all my replicas.
Now I'm not sure if I would be able to just spin up another ESXI server incase of a compromised infrastructure, roll back that Zvol and mount that datastore to a new ESXI server and start up the servers.
As you can see, your idea seems better But I don't know if mine would work, nor it that would be more efficient block-level wise for zfs snapshotting compared to the incremental backup chain.
I currently have veeam b&r on windows and most of the backups also on a windows machine but due to those being vulnerable to a host of exploits and microsoft products being microsoft products , pass the hash , bugs , etc ...
I want to protect against ransomware that would have compromised the veeam server and the backup server. So I also have a freenas server I was planning to use. I also thought about how the currrent backups create a full , incrementals and then sometimes synthetic incrementals and how snapshotting this, would result in too much space usage and perhaps weird 'states'.
I did not think about using reverse increments .... I was thinking about an approach much too complicated I think.
I was going to create a Zvol on freenas, use it as a iscsi datastore on an ESXI server and have veeam do replication of my veeams to that esxi server on that freenas datastore, thinking that if those replicas are just offline, they would not consume any cpu/ram resources from that esxi , nor space since they would be sitting on the extra datastore iscsi from freenas.
And than i'd snapshot that Zvol, which would basicly be snapshots of the entire datastore containing all my replicas.
Now I'm not sure if I would be able to just spin up another ESXI server incase of a compromised infrastructure, roll back that Zvol and mount that datastore to a new ESXI server and start up the servers.
As you can see, your idea seems better But I don't know if mine would work, nor it that would be more efficient block-level wise for zfs snapshotting compared to the incremental backup chain.
Who is online
Users browsing this forum: No registered users and 4 guests