Volume Backup Fails if NTFS mounted

[allanhitch]

Ok. I've got a weird one.

I have NOT opened a "Support case" because I'm pretty sure I'm the one doing something wrong...
I'm also using the Free version, as I (hopefully) find new and marvelous ways to get my boss a little more on-board with Veeam.

I've got a box with a pantload of drives and I don't necessarily want to back them all up in one major job, so I need to do a volume-based "OS" backup.
I CAN do a Volume-based backup if all the NTFS volumes are selected, but if I choose to deselect one (in my experimental box, the volume is "volumelabel" and is /dev/sdb1), the backup fails with the messages:

Code: Select all

   11:54:18        Job Cent7 started at 2018-02-12 11:54:18 EST
      11:54:19        Preparing to backup
      11:54:19        [error] Failed to create volume snapshot                                       00:00:13
      11:54:32        [error] Failed to perform backup
      11:54:32        [error] Snapshot data file [/Mounts/volumelabel/veeamsnapstore.{6b5ccd04-4f9...
      11:54:32        [error] Failed to allocate data file for snapshot storage
      11:54:32        [error] Failed to create snapstore
      11:54:32        [error] Processing finished with errors at 2018-02-12 11:54:32 EST

Selecting this volume, along with /dev/sdax partitions (/, swap, /boot) works like a charm. It also works if I select "Entire Machine", but I don't want to backup all the drives, just a couple of them.)

Veeam 2.0.0.400-1.el7
Cent 3.10.0-693.11.6.el7.x86_64
kmod-veeamsnap.x86_64 2.0.0.400-1.el7

I'm also experimenting on a smaller unit, with only one extra drive that I can format at-will. When I change the partition type to anything ext, I can de-select it and the backup runs fine.

What am I missing?

Thanks!

-Al

[PTide]

Hi,

No, you're doing it just right, it's a known bug and you should contact support team for a workaround. Once you contact them please refer to the previous case where a similar problem was with allocating a snapshot on ReiserFS.

Thank you!

[allanhitch]

Hi,

No, you're doing it just right, it's a known bug and you should contact support team for a workaround. Once you contact them please refer to the previous case where a similar problem was with allocating a snapshot on ReiserFS.

Thank you!

AHA!

Thank you for the sanity check!

I saw a thread pertaining to the ReiserFS. I'll go look a little deeper into that one.
I feel that I should do some homework before actually opening a ticket, but I will do that.

Thank you!

[allanhitch]

Case # 02611206

[allanhitch]

Ok. Well... Looks like we have a solution.

It seems that if an NTFS volume is mounted, but de-selected, Veeam, for some reason, still wants to use the volume for a temp file. Also, if "/dev/sda" doesn't happen to be where the OS resides, and "/dev/sda" happens to be one of the excluded NTFS volumes, Veeam will choke.

The solution is to modify the veeam.ini file with the following:

Under [Snapshot]
Change "type" to "common"
type=common

and change "location" to "/"
location=/

I was also given a command to run: "set -i '/allocation= generic/d' /etc/veeam/veeeam.ini", which, of course, would change the value for "allocation", if it exists in the .ini file.

Unfortunately, the word "allocation" wasn't in any of my veeam.ini files (I was experimenting with different machines), so that directive never took. Since I can't find information pertaining to the directives in the veeam.ini file, I wouldn't know what section it should go under.

At any rate, if you make these changes, be aware that the location of the temp file will be the root directory. If you have a machine with a minimal root size, this could be a problem, so you may want to consider adding a volume somewhere to do that, and keep it excluded from your backup.

Judging from the lack of replies to this thread, I'm going to assume that it isn't a problem for most. If, however, you find yourself with a similar environment and similar problems, this should work... for now...