0

I'm currently running Ubuntu 20.04.4 LTS.

Four times over the past year or two, my apt database got screwed up somehow (I don't know how), and the next time I ran apt, apt-get, and aptitude, I was told that I have more than 1,000 packages that are set up to be removed. If I did an autoremove with the intention of later trying to reinstall, my entire system would have become unusable, because most of the normal, everyday programs would then have been removed during that autoremove.

I did not (!!!) delete the top-level desktop package, nor any top-level package. This error occurred due to something (??? I don't know what) which somehow damaged the integrity of the apt databases on my machine.

I was able to fix this each time by going through the procedure which I have outlined in the "Answer" to this question: Fixing broken apt **without** destroying my system via "apt autoremove"

However, the fact that this has occurred multiple times means that whatever caused this might cause it to happen again. In order to help fix this situation if/when it happens again, I'd like to know the following ...

What directories on my system should I back up if I want to preserve the state of the entire apt system at any given time? I want to take periodic backups of all of these apt-related directories, so that next time this error occurs, I could quickly restore my apt environment by restoring all of these directories to their last backed-up versions.

Thank you for any pointers and suggestions as to what directories I should back up in order to preserve the integrity of my entire apt environment.

HippoMan
  • 455
  • I wonder what you are doing that causes this? It seems to have happened to you two times or so. I have multiple machines running for almost a decade now and have never experienced it. – Organic Marble Jun 23 '22 at 18:01
  • 1
    I'm guessing that it might be related to aptitude, since I use it for most of my apt-related tasks. Occasionally, aptitude hangs and crashes, perhaps due to intermittent network glitches during the time that it's running. I wonder if an aptitude crash at the wrong moment might somehow end up corrupting the apt database. In any case, if I could find out what are all of the directories which comprise this apt database, I could back them up and restore them whenever this might occur in the future. – HippoMan Jun 24 '22 at 15:42
  • PS: I discovered /var/lib/dpkg. Could that be the only directory tree that I would need to back up and restore? I think there might be other package information somewhere else which aptitude uses, but I don't know where. – HippoMan Jun 24 '22 at 15:51
  • You might find this post useful. – Raffa Jun 24 '22 at 17:37
  • Thank you very much. I'm pretty sure that I found and tried that in the past when I encountered this problem, and something about it didn't work. I don't recall what. That is part of the reason for why I want to know how to restore the apt database, rather than try to use apt-based or dpkg-based utilities to fix a broken apt database. Those utilities are likely to also depend on the contents of this database, and if it's hosed, the utilities could also fail. – HippoMan Jun 24 '22 at 17:43

2 Answers2

0

I have part of the answer. Install TimeShift

It takes snapshot of your system and lets you restore to previous state. I like it cause you can create a daily schedule and set how many days of restore to retain. 'Set it and forget it'

Let us know if this helped and a good enough solution.

apt-clone seems to be one option or

How to backup settings and list of installed packages

here is a little info off the page, but lots of other ideas

So all together as a pseudo-bash script (possible one-liner version)

This assumes there is only one user on the machine (remove /'whoami' otherwise) and that you used the same username on both installs (modify dest. of rsync otherwise).

dpkg --get-selections > ~/Package.list && sudo cp -R /etc/apt/sources.list* ~/ && sudo apt-key exportall > ~/Repo.keys && rsync --progress /home/whoami /path/to/user/profile/backup/here

Reinstall now

rsync --progress /path/to/user/profile/backup/here /home/whoami && sudo apt-key add ~/Repo.keys && sudo cp -R ~/sources.list* /etc/apt/ && sudo apt-get update && sudo apt-get install dselect && sudo dpkg --set-selections < ~/Package.list && sudo dselect

Czar
  • 580
  • Thank you very much. TimeShift indeed looks like a useful utility. However, it turns out that three of my servers are managed at Linode and daily system backups are already being performed. I can always restore from those daily backups, but it's a time-consuming process. My other server is at home, and I do my own daily backups which also can be restored. But what I'm trying to do is a more targeted restore of *only* the apt database, instead of the entire system. That's why I want to know what specific directories that are used by apt would need to be backed up and restored. – HippoMan Jun 23 '22 at 13:30
0

I discovered that /var/lib/dpkg is probably the directory tree that I should back up and restore.

But that's specifically for apt and dpkg, and it doesn't necessarily contain everything that aptitude uses, since aptitude is a newer utility which built upon apt.

I'll treat this as a provisional answer until I find out more about the database in which aptitude stores its own data.

UPDATE

I now see the following files: /etc/cron.daily/dpkg and /etc/cron.daily/aptitude. These do the backups of the dpkg database and the aptitude database, respectively.

So, my work is already being done by the OS, and if my apt environment ever gets hosed again, I believe that I can restore it by restoring from those backups.

Onward!

HippoMan
  • 455
  • aptitude is not "a newer utility". – Pilot6 Jun 24 '22 at 16:14
  • OK, but nonetheless, aptitude is built on top of apt, and it has its own database, separate from /var/lib/dpkg.

    Also, I discovered that the backups I need are already being done. See the UPDATE in my answer, above.

     – HippoMan Jun 24 '22 at 16:39