Backup running at the wrong time

Tacioandrade

Renowned Member
Sep 14, 2012
120
17
83
Vitória da Conquista, Brazil
I have some Proxmox running on OVH in Canada, after installing them I ran the command dpkg-reconfigure tzdata and corrected the time zone for Brazil (UTC- 3), but even after doing this when I put Proxmox to perform a backup task as 5:30 am, the backup is running at 1:30 am in the Brazilian time zone.

The strange thing is that in Tasks the time appears correctly, but the time zone in the backup scheduler is incorrect.

Has anyone ever experienced this?

PVE 6.3-4

1615180004023.png

1615180025261.png

1615180139023.png
 
From what I'm seeing, only the ntp service is running, I tried to stop it to activate timesyncd, but even stopping the ntp service, timesyncd does not start and returns this error when I try to check the status.

1615342601315.png

1615342795875.png
 
Last edited:
This has just started happening to me, and I'm suspecting the issue is on the OVH template. I had a 3 node cluster with them, that started with 5.x and was upgraded to 6. Now, in the last few days I ordered 3 new servers to replace them, installed them with the 6.x template, joined the cluster and backups now run 3 hours ahead (I'm in Argentina, my TZ is also -3).
I haven't got rid of the old nodes yet, on them, I get this from timedatectl
Code:
root@prox1:~# timedatectl
               Local time: Fri 2021-07-16 00:38:36 -03
           Universal time: Fri 2021-07-16 03:38:36 UTC
                 RTC time: Fri 2021-07-16 03:38:36
                Time zone: America/Argentina/Buenos_Aires (-03, -0300)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

root@prox1:~# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Sat 2021-06-19 06:10:11 -03; 3 weeks 5 days ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 16716 (systemd-timesyn)
   Status: "Synchronized to time server for the first time 213.251.128.249:123 (ntp.ovh.net)."
    Tasks: 2 (limit: 4915)
   Memory: 4.4M
   CGroup: /system.slice/systemd-timesyncd.service
           └─16716 /lib/systemd/systemd-timesyncd

Jun 19 06:10:11 prox1 systemd[1]: Starting Network Time Synchronization...
Jun 19 06:10:11 prox1 systemd[1]: Started Network Time Synchronization.
Jun 19 06:10:11 prox1 systemd-timesyncd[16716]: Synchronized to time server for the first time 213.251.128.249:123 (ntp.

On the new nodes I get:
Code:
root@prox01:~# timedatectl
               Local time: Fri 2021-07-16 00:41:36 -03
           Universal time: Fri 2021-07-16 03:41:36 UTC
                 RTC time: Fri 2021-07-16 03:41:36
                Time zone: America/Argentina/Buenos_Aires (-03, -0300)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no
          
root@prox01:~# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Fri 2021-07-16 00:30:17 -03; 11min ago
           └─ ConditionFileIsExecutable=!/usr/sbin/ntpd was not met
     Docs: man:systemd-timesyncd.service(8)

Jul 16 00:30:17 prox01 systemd[1]: Condition check resulted in Network Time Synchronization being skipped.
 
This has just started happening to me, and I'm suspecting the issue is on the OVH template. I had a 3 node cluster with them, that started with 5.x and was upgraded to 6. Now, in the last few days I ordered 3 new servers to replace them, installed them with the 6.x template, joined the cluster and backups now run 3 hours ahead (I'm in Argentina, my TZ is also -3).
I haven't got rid of the old nodes yet, on them, I get this from timedatectl
Code:
root@prox1:~# timedatectl
               Local time: Fri 2021-07-16 00:38:36 -03
           Universal time: Fri 2021-07-16 03:38:36 UTC
                 RTC time: Fri 2021-07-16 03:38:36
                Time zone: America/Argentina/Buenos_Aires (-03, -0300)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

root@prox1:~# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Sat 2021-06-19 06:10:11 -03; 3 weeks 5 days ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 16716 (systemd-timesyn)
   Status: "Synchronized to time server for the first time 213.251.128.249:123 (ntp.ovh.net)."
    Tasks: 2 (limit: 4915)
   Memory: 4.4M
   CGroup: /system.slice/systemd-timesyncd.service
           └─16716 /lib/systemd/systemd-timesyncd

Jun 19 06:10:11 prox1 systemd[1]: Starting Network Time Synchronization...
Jun 19 06:10:11 prox1 systemd[1]: Started Network Time Synchronization.
Jun 19 06:10:11 prox1 systemd-timesyncd[16716]: Synchronized to time server for the first time 213.251.128.249:123 (ntp.

On the new nodes I get:
Code:
root@prox01:~# timedatectl
               Local time: Fri 2021-07-16 00:41:36 -03
           Universal time: Fri 2021-07-16 03:41:36 UTC
                 RTC time: Fri 2021-07-16 03:41:36
                Time zone: America/Argentina/Buenos_Aires (-03, -0300)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no
         
root@prox01:~# systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: inactive (dead)
Condition: start condition failed at Fri 2021-07-16 00:30:17 -03; 11min ago
           └─ ConditionFileIsExecutable=!/usr/sbin/ntpd was not met
     Docs: man:systemd-timesyncd.service(8)

Jul 16 00:30:17 prox01 systemd[1]: Condition check resulted in Network Time Synchronization being skipped.
So it is! After a problem I had with the OVH template for Proxmox where when I updated it wouldn't start due to a problem with vmbr (it got stuck and wouldn't start), I stopped using it and always install via IPMI, because OVH support is garbage, they generate buggy templates and when there is a problem, they don't help users.

After that I installed Proxmox directly by ISO in 80% of the hosts I have there and I'm no longer facing these problems.
 
So it is! After a problem I had with the OVH template for Proxmox where when I updated it wouldn't start due to a problem with vmbr (it got stuck and wouldn't start), I stopped using it and always install via IPMI, because OVH support is garbage, they generate buggy templates and when there is a problem, they don't help users.

After that I installed Proxmox directly by ISO in 80% of the hosts I have there and I'm no longer facing these problems.
So far this was the only issue I faced, will try to find what's wrong with the backup time, for now I just added 3 hours for my backup time as reinstalling and resyncing would be painful right now.
@Moayad , anything else you can suggest?
 
  • Like
Reactions: Tacioandrade
Turns out that my issue was simpler than what I expected. I changed the timezone from the GUI, but as cron was running it kept using the old TZ. I had to
Bash:
systemctl restart cron
and from then on, backups are happening at the expected time.

@Moayad , don't you think PVE should take care of restarting cron after a TZ change?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!