• EN
Solved

immutability flag

V
Userlevel 5

Hey everyone,

We've encountered an issue with our immutable backup setup. We've configured our Ubuntu server to shut down after completing the backup, turning it on before initiating the backup process. As a result, the server shuts down at 1 AM every day after finishing its backup routine.

However, once a week, we receive the following error message. I've been able to resolve it by deleting the file, but it keeps reappearing. Is there a way we can extend the immutability time to avoid this issue recurring?

 

 

A problem occurred during setting the immutable flag: repository time shift detected, immutability flag cannot be set. Please refer to KB4482 for more details
Processing finished with warnings at 3/17/2024 10:33:16 PM

icon

Best answer by Iams3le 18 March 2024, 13:54

View original

9 comments

Link State
Userlevel 7
Badge +8

Hi @VEEAM_Legend 

have you configured ntpd for time sync?
It seems that the VM's time is not synchronised, or or am I wrong?

Veeam: VMCA | VMCE | VMXP | Veeam Legend - Microsoft: MCITP | MCP | MCSA | 2008 R2 | 2012R2 | 2016 | MCSE Core Infrastructure | MCSE Cloud Platform - Azure: AZ900 | AZ104 - VMWare: VCP-DCV Vsphere 7.x - Cisco: CCNA (Expired)
Stabz
Userlevel 7
Badge +7

Hey,
Have you check the KB?
https://www.veeam.com/kb4482#:~:text=This%20warning%20is%20displayed%20when,immutability%20state%20from%20being%20manipulated.

 

Advanced Configuration

The TimeShift detection feature is configurable by creating the file /etc/veeam/immureposvc/config and setting parameters as desired.

The config file must be created with permissions 600 and belong to the root user.

Available Parameters:

  • disableCheck - parameter responsible for the general enabling or disabling of the functionality.
  • checkHwTime - controls whether the HW time is checked. Some systems may not have this clock.
  • maxDeltaValueInSec - determines the value of shifted time after which the retention is blocked.

Example config file formatting with default settings:

<TimeDefenderConfig disableCheck="0" checkHwTime="1" maxDeltaValueInSec="86400" />

After creating or modifying the config file, the veeamtransport service must be restarted.

Note: The config file overrides the hardcoded defaults; if it is not present or not configured as documented, the defaults will be used.

 

Philippe DUPUIS |Veeam Certified Engineer | https://original-network.com/
V
Userlevel 5

Hi @VEEAM_Legend 

have you configured ntpd for time sync?
It seems that the VM's time is not synchronised, or or am I wrong?

 

the VEEAM is not part of the domain, but the time is same as the DC.
do you mean something else?

V
Userlevel 5

Hey,
Have you check the KB?
https://www.veeam.com/kb4482#:~:text=This%20warning%20is%20displayed%20when,immutability%20state%20from%20being%20manipulated.

 

Advanced Configuration

The TimeShift detection feature is configurable by creating the file /etc/veeam/immureposvc/config and setting parameters as desired.

The config file must be created with permissions 600 and belong to the root user.

Available Parameters:

  • disableCheck - parameter responsible for the general enabling or disabling of the functionality.
  • checkHwTime - controls whether the HW time is checked. Some systems may not have this clock.
  • maxDeltaValueInSec - determines the value of shifted time after which the retention is blocked.

Example config file formatting with default settings:

<TimeDefenderConfig disableCheck="0" checkHwTime="1" maxDeltaValueInSec="86400" />

After creating or modifying the config file, the veeamtransport service must be restarted.

Note: The config file overrides the hardcoded defaults; if it is not present or not configured as documented, the defaults will be used.

 

thank you for your answer.
i am aware of this. once a week i have to follow those steps to get it resolved.
 

Link State
Userlevel 7
Badge +8

Hi @VEEAM_Legend 

have you configured ntpd for time sync?
It seems that the VM's time is not synchronised, or or am I wrong?

 

the VEEAM is not part of the domain, but the time is same as the DC.
do you mean something else?

i use ubuntu as my immu repo and set ntp external time sync
https://wiki.ubuntu-it.org/Server/SincronizzazioneTempoNtp

https://reintech.io/blog/configuring-ntp-client-ubuntu-2004

Veeam: VMCA | VMCE | VMXP | Veeam Legend - Microsoft: MCITP | MCP | MCSA | 2008 R2 | 2012R2 | 2016 | MCSE Core Infrastructure | MCSE Cloud Platform - Azure: AZ900 | AZ104 - VMWare: VCP-DCV Vsphere 7.x - Cisco: CCNA (Expired)
Iams3le
Userlevel 7
Badge +9

Hi @VEEAM_Legend, This first part does not directly address your question but might be an option to consider the Object First appliance since it handles all these issues under the hood without requiring advanced expertise to manage the box.

The warning message due to Time Shift is also addressed here: https://www.veeam.com/kb4424. You have some good links shared above to have this issue resolved.

[Microsoft MVP | Veeam Legend 5* | VMware vExpert 4* | Cisco Champion 3* | Object First Ace]
Chris.Childerhose
Userlevel 7
Badge +20

Hey,
Have you check the KB?
https://www.veeam.com/kb4482#:~:text=This%20warning%20is%20displayed%20when,immutability%20state%20from%20being%20manipulated.

 

Advanced Configuration

The TimeShift detection feature is configurable by creating the file /etc/veeam/immureposvc/config and setting parameters as desired.

The config file must be created with permissions 600 and belong to the root user.

Available Parameters:

  • disableCheck - parameter responsible for the general enabling or disabling of the functionality.
  • checkHwTime - controls whether the HW time is checked. Some systems may not have this clock.
  • maxDeltaValueInSec - determines the value of shifted time after which the retention is blocked.

Example config file formatting with default settings:

<TimeDefenderConfig disableCheck="0" checkHwTime="1" maxDeltaValueInSec="86400" />

After creating or modifying the config file, the veeamtransport service must be restarted.

Note: The config file overrides the hardcoded defaults; if it is not present or not configured as documented, the defaults will be used.

 

I am going test these settings as I am doing a similar thing when I have HA events in VMware with my VHRs.  This is probably the best workaround.

I do have the VMTools set to sync for both options as well.

Chris Childerhose - VMCA2022 | VMCE2023 | Veeam Vanguard 7* | Veeam Legend 3* | vExpert 5* | VCAP-DCV/VCP-DCV | Object First Ace | Cisco Champion | Twitter: @cchilderhose | Blog Site – https://just-virtualization.tech
V
Userlevel 5

Hey,
Have you check the KB?
https://www.veeam.com/kb4482#:~:text=This%20warning%20is%20displayed%20when,immutability%20state%20from%20being%20manipulated.

 

Advanced Configuration

The TimeShift detection feature is configurable by creating the file /etc/veeam/immureposvc/config and setting parameters as desired.

The config file must be created with permissions 600 and belong to the root user.

Available Parameters:

  • disableCheck - parameter responsible for the general enabling or disabling of the functionality.
  • checkHwTime - controls whether the HW time is checked. Some systems may not have this clock.
  • maxDeltaValueInSec - determines the value of shifted time after which the retention is blocked.

Example config file formatting with default settings:

<TimeDefenderConfig disableCheck="0" checkHwTime="1" maxDeltaValueInSec="86400" />

After creating or modifying the config file, the veeamtransport service must be restarted.

Note: The config file overrides the hardcoded defaults; if it is not present or not configured as documented, the defaults will be used.

 

I am going test these settings as I am doing a similar thing when I have HA events in VMware with my VHRs.  This is probably the best workaround.

I do have the VMTools set to sync for both options as well.

i am curious if you'll get it fixed.
i dont have time to configure it yet.
 

Hubert Brychczynski

Hi there! As a side note, you seem to be running a Veeam Hardened repository in a VM. Is that correct? If so, I wonder if this doesn’t make you vulnerable at the hypervisor level. From a Zero Trust standpoint, maybe it’s worth considering a physical server instead?

Hubert

Comment


Terms & Conditions