[warn] Mount point for repository changed

[Hejah]

Hello,
I have changed the backup repository via command line (added a new repo, changed the repo in the backup job and removed the old repo).

After that I get with every backup the warning:

[warn] Mount point for repository changed

what do I need to change get rid of this warning.

I have restarted the veeamservice.service, that didn't change anything.

The only idea I currently have is to remove and rebuild /var/lib/veeam/veeam_db.sqlite.
But then I lose the information about the backups and the easy way to restore them.

So is there a better way to fix this warning?

Besides the warning (which I would only expected in the first run) every thing is working.
Veeam Agent for Linux FREE v2.0.1.665

Thanks

[PTide]

Hi,

This is a known bug, our QA team is aware of it. I'll update this thread once I get some workaround other than deleting the database.

Thank you for your report!

[AlexLeadingEdge]

I have this same issue. I simply go into Configuration and save everything again and it seems to clear that flag.

[Hejah]

I had tried that and it didn't work.
I have rebuilt the configuration Database on the affected system.
So I have currently no system to test that again.

[Hejah]

Hello,
are there any updates regarding this issue?

The problem seems to be still present in Veeam 3.0.2.1185.

A change occurred once but I get the warning forever.

Is there a value in the veeam_db.sqlite Databas I can change to fix this message?

Kind regards

[Retrofreak]

Just found this thread. I am running Veeam 3.0.2.1185 on my private homeserver (seems this is still the latest version?). Debian Stretch. And I am also wondering about this "mount-point changed" warning regarding the logs. Curiously sometimes - without any changes - it logs "success"

Example Logs:

Code: Select all

      02:05:01         Job MASTER-BACKUP started at 2020-04-02 02:05:01 GMT
      02:05:01         [warn] Mount point for repository changed

Code: Select all

      MASTER-BACKUP                         Warning         2020-04-01 02:05:01   2020-04-01 02:32:49  ▒
      MASTER-BACKUP                         Warning         2020-03-31 02:05:01   2020-03-31 02:24:33  │
      MASTER-BACKUP                         Warning         2020-03-30 02:05:02   2020-03-30 02:21:56  │
      MASTER-BACKUP                         Warning         2020-03-29 03:00:01   2020-03-29 03:18:24  │
      MASTER-BACKUP                         Warning         2020-03-28 02:05:01   2020-03-28 02:24:59  │
      MASTER-BACKUP                         Success         2020-03-27 02:05:01   2020-03-27 02:26:51  │
      MASTER-BACKUP                         Warning         2020-03-26 02:05:01   2020-03-26 02:22:59  

Perhaps someone can explain this mystery?
Thanks for attention and greetings!

[adrian_vg]

Hi,

This is a known bug, our QA team is aware of it. I'll update this thread once I get some workaround other than deleting the database.

Thank you for your report!

Is there any recent status update on this issue?
I'm seeing this Veaam for linux agent v5.0.2.4567.

Using Kubuntu 22.04 Jammy and backing up to a a Synology-NAS with a NFS-share.

Code: Select all

Backup                                        100%                                       Status: Warning  100%



Summary                              Data

Duration:           00:49:05         Processed:          1.2 TB (100%)
Processing rate:    446.8 MB/s       Read:               1.2 TB
Bottleneck:         Target           Transferred:        52.5 GB (22.6x)

Time             Action                                                                      Duration

08:00:01         Job Daily_new3 started at 2022-11-03 07:00:01 UTC
08:00:02         [warn] Mount point for repository changed
08:00:02         Preparing to backup
08:00:04         Creating volume snapshot                                                    00:00:02
08:00:06         Starting incremental backup to Repository_1
08:00:06         Backed up sda 513.3 MB at 73.2 MB/s                                         00:00:07
08:00:15         Backed up vgkubuntu 195.4 GB at 254.5 MB/s                                  00:13:07
08:13:29         Backed up md0 992.1 GB at 528.5 MB/s                                        00:32:02
08:45:31         Backing up summary.xml                                                      00:00:00
08:45:34         Releasing snapshot                                                          00:00:03
08:45:37         Applying retention policy                                                   00:03:29
08:45:38         Full backup file merge completed successfully                               00:03:27
08:49:06         [warn] Processing finished with warnings at 2022-11-03 07:49:06 UTC

[PTide]

The issue has been fixed long ago and is not supposed to be in v5.

Let's confirm your case: you changed local repo settings (location) and now you are getting the warning in every backup session?

thanks!

[adrian_vg]

Hello @PTide!

Thanks for getting back to me!

I didn't change any location, that's the weird thing.

I use a 5 TB USB-disk connected straight into my laptop, to which the Veeam linux agent does a daily backup.
My laptop normally sits in its dock most of the time, as I also WFH. So no real reason the 5 TB-disk should jump around on the mounting points.

What I've seen so far, is that whenever I create a new schedule, the backup seems to work successfully for a while, then start showing the warnings.

A speculation, should/would the mount points change for the 5 TB-disk depending if I'm logged on or logged out of the computer?

Also in /etc/fstab I've added a line to always mount the 5 TB-disk in a specific folder, just to avoid issues like mountpoint-hopping.
The backup is done by the root account, right?
So I'm sort of assuming the mounts shouldn't change, like it sometimes does when I login as myself (not root) to the desktop GUI.

Does this make any sense at all?
If you need more info, please ask!

[adrian_vg]

An update
Edited the backup job to not use "local" and the locally mounted folder pointing to my NAS.
I'm now trying "shared folder" method, pointing directly to the shared folder on the NAS.

My first backup show no warning as of yet.


Another update
Three consecutive backups have been made. All three successful and no warnings.

https://imageshack.com/i/pmsKFlWsp
https://imageshack.com/i/pnHZGwfMp

Will run like this for a while and see that all backups are successful.
Reporting back in a few days.

[adrian_vg]

Yet another update

I've been running the backup for the last four days now, connected directly to the NAS share, and all of the backups have finished successfully.
I think I'll call the problem solved in my case.

Thanks all for the assistance!

[adrian_vg]

Final update on the mount point changed issue

For posterity, I've been running the backup as stated above, directly connected to the nfs-share on the NAS, for the last ten days.
All backups were successful.
For me the issue is now considered resolved.

Thanks again everybody for their assistance!

[PTide]

Glad that you've figured it out!

Two more questions though:

- did you use any scripts (agent pre-job scripts, or separate scripts started by cron) to mount your target repo (be it USB 5 TB or NAS)?
- any chance that the USB device designation has changed (e.g. it used to be /dev/sdb1 and changed to /dev/sdb2)?

Thanks!

[adrian_vg]

- did you use any scripts (agent pre-job scripts, or separate scripts started by cron) to mount your target repo (be it USB 5 TB or NAS)?

No, no scripts used. Unless the OS itself does something.

The previous non-working mount I did from /etc/fstab.
The line looked like this:

Code: Select all

192.168.0.15:/volume1/veeam_backup_agent /home/veeam-backup            nfs auto,nofail,relatime,nolock,intr,tcp,actimeo=1800  0 0

The currently working "mount" is just a pointer from within the veeam agent to 192.168.0.15:/volume1/veeam_backup_agent.

- any chance that the USB device designation has changed (e.g. it used to be /dev/sdb1 and changed to /dev/sdb2)?

I can't check that right now, laptop at work seems unresponsive...
But IIRC, I've mounted the USB-device using a UUID to point to a set folder as above in /home, from /etc/fstab.
It shouldn't jump around I think, with this setup.

In my experience USB-devices have a tendency to jump around a bit when just plugging them in, or rebooting the computer they're connected to.
The above mount line in fstab, should take care of the jumping around, or so does the interweb say.