Backup of boot partition content: file not found

I have recently set up a FreeBSD 13 server with mirrored ZFS. The daily mail reports this message:

Code:
Backup of boot partition content:
ada0p2
mv: rename /var/backups/boot.ada0p2.tmp to /var/backups/boot.ada0p2.bak: No such file or directory
ada1p2
mv: rename /var/backups/boot.ada1p2.tmp to /var/backups/boot.ada1p2.bak: No such file or directory

I haven't tweaked the system much, so I am wondering what the cause of the error is and what I should do to fix it.
 
There's a scheduled daily cronjob (/etc/crontab), the script /etc/periodic/daily/221.backup-gpart. Try to run manually to see if the backup gets through. Maybe it fails within the script for some reason (dd of the boot part failing?).
 
dd stderr is sent to /dev/null (probably to shut up the stats)
you need to copy the script to tmp, remove 2>/dev/null from the dd lines and see what really happens
 
I have followed your suggestions, but when I execute the script manually, it goes through just fine and exits with code 0. That's the output:

Code:
$ /tmp/221.backup-gpart                                          
                                                                
Dump of kern.geom.conftxt:                                      
                                                                
Backup of partitions information for:                           
ada0                                                            
ada1                                                            
ada2                                                            
                                                                
Backup of boot partition content:                               
ada0p2                                                          
1024+0 records in                                               
1024+0 records out                                              
524288 bytes transferred in 0.117460 secs (4463549 bytes/sec)   
ada1p2                                                          
1024+0 records in                                               
1024+0 records out                                              
524288 bytes transferred in 0.092269 secs (5682153 bytes/sec)

What I have seen with further debugging is that rotate() executes the then branch and just removes the .tmp file. It seems, however, that when executed as a cron job, the script runs the else part of the function, trying to rename the .tmp file. I don't know why.
 
no idea, like the cron script has no /var/backups or somehow dd fails from whatever reason
best idea to put the modified version in /etc/periodic/daily
you also may add a "set -x" at the top of the file (after "#!/bin/sh"
 
There it is:

Code:
$ ls -al /var/backups 
total 5690
drwxr-x---   2 root  wheel      27 Nov 26 14:12 .
drwxr-xr-x  24 root  wheel      24 Nov 11 18:51 ..
-rw-r--r--   1 root  wheel    1624 Apr  9  2021 aliases.bak
-rw-r--r--   1 root  wheel  524288 Oct 26 03:01 boot.ada0p2.bak
-rw-r--r--   1 root  wheel  524288 Oct 26 03:01 boot.ada1p2.bak
-rw-r--r--   1 root  wheel     512 Oct 26 03:01 boot.ada2.bak
-rw-r--r--   1 root  wheel     208 Oct 27 03:01 gpart.ada0.bak
-rw-r--r--   1 root  wheel     197 Oct 26 03:01 gpart.ada0.bak2
-rw-r--r--   1 root  wheel     208 Oct 27 03:01 gpart.ada1.bak
-rw-r--r--   1 root  wheel     197 Oct 26 03:01 gpart.ada1.bak2
-rw-r--r--   1 root  wheel      63 Oct 27 03:01 gpart.ada2.bak
-rw-r--r--   1 root  wheel       6 Oct 26 03:01 gpart.ada2.bak2
-rw-r--r--   1 root  wheel      47 Nov 21 03:01 gpart.da0.bak
-rw-r--r--   1 root  wheel     495 Oct 26 12:54 group.bak
-rw-r--r--   1 root  wheel     477 Oct 24 17:18 group.bak2
-rw-r--r--   1 root  wheel    1246 Nov 22 03:01 kern.geom.conftxt.bak
-rw-r--r--   1 root  wheel    1394 Nov 21 03:01 kern.geom.conftxt.bak2
-rw-------   1 root  wheel    2149 Nov  6 16:13 master.passwd.bak
-rw-------   1 root  wheel    2139 Oct 26 15:16 master.passwd.bak2
-rw-r--r--   1 root  wheel  731248 Nov 26 03:01 pkg.sql.xz
-rw-r--r--   1 root  wheel  731248 Nov 25 03:19 pkg.sql.xz.1
-rw-r--r--   1 root  wheel  731248 Nov 24 03:03 pkg.sql.xz.2
-rw-r--r--   1 root  wheel  731292 Nov 23 03:01 pkg.sql.xz.3
-rw-r--r--   1 root  wheel  731292 Nov 22 03:26 pkg.sql.xz.4
-rw-r--r--   1 root  wheel  731292 Nov 21 03:07 pkg.sql.xz.5
-rw-r--r--   1 root  wheel  499672 Nov 20 03:02 pkg.sql.xz.6
-rw-r--r--   1 root  wheel  499644 Nov 19 03:43 pkg.sql.xz.7

/var/backups itself is 750, root:wheel.
 
Alright, those permissions look good. Can you show the output from gpart show ada0 and/or gpart show ada1?
 
I think everything is in order there:

Code:
$ gpart show ada0
=>        40  7814037088  ada0  GPT  (3.6T)
          40      532480     1  efi  (260M)
      532520        1024     2  freebsd-boot  (512K)
      533544         984        - free -  (492K)
      534528     4194304     3  freebsd-swap  (2.0G)
     4728832  7809306624     4  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)

can you verify that by some sort of mistake you don't have this script scheduled more times ?
May it be that the script is triggered from within some jail? How do I check whether it is scheduled more than once?
 
May it be that the script is triggered from within some jail?
Then root in the jail would get that email, not root on the host. In a jail you can turn this off by adding daily_backup_gpart_enable="NO" to /etc/periodic.conf.
 
Then root in the jail would get that email, not root on the host.
Ah, bingo! I get periodic emails from each jail. I got confused because (a) each jail reports the same error, and (b) I have forgotten to set up email forwarding for the host ?. So, I was believing that the error is in the host while, in fact, the problem is in each and every jail I have set up.

In fact, I can reproduce it in a jail by running the cron script manually. I am going to re-apply your suggestions to figure out why.
 
Yes, it's going to fail in a jail because it doesn't have access to the disk directly. Just turn off that check in /etc/periodic.conf on each jail. It's pointless to do this in a jail anyway, the host is already making those backups.
 
Done, thanks. Is there any reference describing which cron jobs should be turned off in jails? AFAIK, the handbook just recommends turning off adjkerntz.
 
well this is kind of a bug
the script should check itself if it jailed and exit because it can't possibly work in a jail
 
Back
Top