I am glad that Veeam now offers this BETA.
Just downloaded and tried out my first time this morning, so this is my first emotional oppinion
Sorry, it's long, I know...
First the short:
Installation on a Mint Linux 18 64bit (which is Ubuntu 16.04 based): no problems.
Then the backup:
I wanted to create "Entire system", but it failed on choosing "local" as a destination:
It's okay to say "/mnt/backup" is part of the entire system, so it cannot be chosen as a destination.
Veeam told me to exclude that directory... but there is no option to exclude it anywhere.
Otherwise choosing /dev/sdd1 should be an option, but even this failed because veeam needed a not a device I think.
The solution should be: Let me choose a directory, but please exclude that automatically from backups when "entire system - local".
So I just created a volume based backup job and chose any volume and partitions except the partition containing the backups.
I have a dedicated disk for local backups in our laptops, so this no problem for me, but I think the next versions should be able to backup even within the same partition and have to bring in "Exclusion" options for the Target-Directories.
The first run took 86 minutes (1TB read from SSD and 385 GB wrote to SATA-disk).
Most annoying was: During that run the system really often becam unresponsive for seconds.
The load average grew up to 7,26 on my Core i7, so the CPU's really were heavy on duty.
Veeam told me "source" had been the bottleneck. Nice to know my SSD is a bottleneck
But it felt my CPU was the bottleneck - it's the first time I really thought my Core i7 4770 is a bottleneck
Tried another run 15 minutes later. That run was "quick" in 6 minutes, read 340MB and wrote 138MB.
Wondering what 138 MB of data changed in that short time.
Reboted the machine and tried another run 2 hours later.. That run needed 38 minutes, read again 1TB and wrote 202MB.
In my oppinion an incremental backup run should not run about 40 minutes (just half the time of a full backup) even after a reboot...
Apropos incrmental backup:
Feature request:
As known from our Veeam enterprise: Will there be an reverse incrmental option someday?
I'm in love with that concept of "reverse incremental" the newest Backup-File alwas is complete and I may just discard the old diffs as my storage goes out of space without needing to do a new Full-Backup. That should become a standard in my humble oppinion
Restore:
Just tried to restore some data (online without the iso) and mounted the Restore point:
The mounted mount points worked so far... but... not every backed up device could be mounted.
May be the thing is:
I have got a luks-encrypted device and backed it up (/dev/sdc1).
So I think there is mission luks-support (at least for restore? Hope the backup worked, he used a lot of time to fully backup the device first time).
Veeam should try to detect luks devices, ask for a password and try to mount it for restore...?
Or is there any manual way to mount that restore-point using luks?
I think it will be the same on Restore with CD:
Does the CD contain everything to support luks encrypted volumes within the backup?
Next thing is:
The backups target-directory itself is stored on a luks-encrypted volume.
Within my running system it's no problem to mount that backup-target-directory and make it accessible to Veeam, but is the iso capable of mounting that encrypted target-filesystem?
To avoid using encrypted filesystems as a target-directory there should be a password option for backup jobs.
Especially for field-workers and their laptops often it is not possible to backup to clouds, so the backup should get local but secure for the case of loosing the hardware.
TLDR:
My first impression is:
Great beta as expected for Veeam product, but like a beta should be: Working but in need of round some corners!
Thank you for that good job until here, guys!
. 
