Does pkg backup still exist?

And you can reference the following commit in https://github.com/freebsd/pkg:
Code: 
commit eea1a990eb1187a408811534a5060e58074a9044
Author: Baptiste Daroussin <bapt@FreeBSD.org>
Date:   Tue Oct 4 17:02:13 2022 +0200

    backup: remove the backup command which was confusing

    backup and backup -r was basically replicating the db, while we now
    prefer a real sql dump.

    with the backup command backuping a corrupted db will succesfully
    backup it and pkg backup -r will sucessfully restore a corrupted db.
    Making its usage quite useless.
 
vieron said:
pkg backup isn't available?
Click to expand...
This is independent a pkg-upgrade(8), now, to manually create a pkg database backup one must execute sh /usr/local/etc/periodic/daily/411.pkg-backup. This will create under /var/backups/ a pkg.sql.xz file and rename the previouse pkg database backups.

Otherwise a daily periodic cron job is run, IF the machine is running at 3 o'clock in the morning, local time.
/etc/crontab
Code: 
# Perform daily/weekly/monthly maintenance.
1       3       *       *       *       root    periodic daily

vieron said:
To be honest it is not very clear to me what the author of the previously mentioned commit means by "we now prefer a real sql dump".
Click to expand...

For a novice in shell scripting it's hard to interpret (like me, I hardly understand it myself), see /usr/local/etc/periodic/daily/411.pkg-backup for sql dump.

In short
Code: 
do_dump() {
         ...
         ${pkgcmd} ${pkgargs} shell .dump
}

backup_pkg() {
        ...
        if do_dump | xz -c > ${bak_file}; then
        ...
        ...
        bak="${daily_backup_pkg_dir:-/var/backups}"
        bak_file="${bak}/pkg.sql.xz"
and
Code: 
 % pkg shell .help | grep .dump
.dump ?OBJECTS?          Render database content as SQL
 
Thank you once again T-Daemon for the clear and detailed information!

T-Daemon said:
his is independent a pkg-upgrade(8)
Click to expand...
It has taken me quite a bit of reading to get an idea of the relation between installed packages and pkg's database. I must say that I found Thread 64361 quite useful in that respect.

T-Daemon said:
do_dump() { ... ${pkgcmd} ${pkgargs} shell .dump }
Click to expand...
Cool, so this is what actually "triggers" pkg's database backup.

I'm guessing that Baptiste Daroussin's commit message about preferring a real sql dump has to do with what they say in the sqlite documentation about the sqlite .dump command:
".dump" stops when the first sign of corruption is encountered.
Click to expand...
 
T-Daemon said:
… cron …
Click to expand...

Given the importance of backups, it's unfortunate that sysutils/anacron is not used.

Code: 
Message from anacron-2.3_8:

--
Configuration hints:
- Edit /usr/local/etc/anacrontab
- Deactivate the 'periodic' commands in /etc/crontab
- Add a call to anacron to /etc/crontab, like
  0  0  *  *  *    root    /usr/local/sbin/anacron
- Add anacron_enable="YES" to /etc/rc.conf
  or execute one of the following commands as root:
    service anacron enable
    sysrc anacron_enable=YES
- Read anacron(8) and anacrontab(5)
- To avoid overlapping periodic(8) jobs, you may want to serialize jobs:
    sysrc anacron_flags+=" -s"


Today a UFS-based system was wrecked (broken pkg database, plus at least one broken binary) with no backup of the database in the five months since FreeBSD was installed ?
1727588762558.png

I peeked at another machine, no backup since November 2023:

1727589340895.png


vieron said:
… I opened PR 271534 as suggested. …
Click to expand...

Result: removal from the FreeBSD Handbook ?

Instead, from a manual page:

Code: 
Restore a backup database:
      % rm /var/db/pkg/local.sqlite
      % xzcat /var/backups/pkg.sql.xz | pkg shell

1727590785205.png
 
I didn't think I had done anything special to get backups but did find
> ls -al /var/backups/pkg.sql.xz*
-rw-r--r-- 1 root wheel 26336564 Sep 29 04:16 /var/backups/pkg.sql.xz
-rw-r--r-- 1 root wheel 26334736 Sep 28 06:07 /var/backups/pkg.sql.xz.1
-rw-r--r-- 1 root wheel 26334736 Sep 27 04:34 /var/backups/pkg.sql.xz.2
-rw-r--r-- 1 root wheel 26527020 Sep 26 07:02 /var/backups/pkg.sql.xz.3
-rw-r--r-- 1 root wheel 26471820 Sep 25 04:47 /var/backups/pkg.sql.xz.4
-rw-r--r-- 1 root wheel 26471820 Sep 24 05:19 /var/backups/pkg.sql.xz.5
-rw-r--r-- 1 root wheel 26611144 Sep 23 05:53 /var/backups/pkg.sql.xz.6
-rw-r--r-- 1 root wheel 26611144 Sep 22 04:33 /var/backups/pkg.sql.xz.7
 on my 14.1-stable system while more recently doing some cleanup; makes me think we can benefit from incremental and deduplication (no, I didn't say ZFS's deduplication) on the backups. Such a change makes the backup files not freestanding but is the goal of having several to have multiple states we can restore to or to have 8 fallbacks in case the original + first seven failed? If the goal is multiple states, we could likely fit many more in much less space.
 
If the system is in a bad state where package backups do not work or are not accurate, I occasionally uninstall all packages, review any remaining debris in relevant locations like /usr/local (few ports have exceptions and write outside this by default), and then reinstall the packages. It has been handy over the years for finding debris from crashes during install (I had a particularly unstable system at one point), accidental aborts at such a bad time, and ports that didn't fully pkg-plist log installed/created files.
Removing+reinstalling all packages takes a bit of time but isn't usually too tedious. I usually use `pkg prime-origins` though other pkg aliases exist and you should check that any list handles tracking a port's category/directory, flavor, and/or version if desired. Instead of using such automated output, I still think it is better to just manually maintain a list of packages you install over time. A manual list takes away any question of if a manually installed dependency will be remembered/kept if its dependents are later removed and can be sorted such as by purpose and additional dependencies/optional ports can be kept next to it in the list. You can also add comments with # in the file and still pass such files to poudriere with -f for building from this curated list.
 
Mirror176 said:
… manually maintain a list of packages you install over time. …
Click to expand...

On my everyday FreeBSD, I keep records of updates and upgrades, but not installations. Occasionally, saved to a file:

pkg prime-origins | sort -u

Luckily, the virtual machine on which it's now impossible to run that command can probably be disposed of …
 
You must log in or register to reply here.
Back
Top