I was wondering what is the best way to backup a Debian system manually without copying installed binaries, just a list to re-download them again. My plan it the following:

Back up a list of packages and repo keys.
Back up /etc
Back up /home
I'm not sure what should I exclude from /etc and what other directories I might want to backup.

For example, the fstab and the grub configuration files in /etc probably must no be copied? Because the new system needs its own after a clean install.

Also, I use snap and it stores some configuration files in /var/lib/snapd
In general, should I backup the whole / and exclude let's say the /bin folder?
But what about /usr/bin , /usr/local/bind etc...
I'm losing my mind thinking all this stuff.

I usually don't install stuff manually or using make install. Any precompiled or
compiled projects from the source are being stored in my home directory with all
their depedencies.

So what should I backup?

Thanks.

Personally I would backup everything with rsync; I do this with nfs boot installs, but for various reasons I don't bother doing this with my traditional installs.

It's a matter of cost vs benefit.

The extra cost of backing up everything is hardly anything. So what if all these binaries are backed up? It doesn't really amount to that much extra space.

The benefit is that I've got a backup of everything in case I need it. If I don't need it? No big deal. If I do? Well, I'll be glad I had it.

Basically, what you're doing is saving a little bit of computer resources at the expense of a lot of human resources. You've got to spend a lot of time figuring out what your plan is and making sure it checks out.

That said, your basic strategy sounds like a good plan for standing up new systems from, say, a slow USB thumbdrive. In that case, it could easily be faster and easier to do a normal install than to clone a file tree.

Also, if you're doing this as a learning experience to get a deeper understanding of how things work, then it could be a worthwhile endeavor regardless.

So what about fstab, /boot, grub config ?

If I install Debian on a new system and then just copy-paste my backed up / tree on the new system
would this cause problems to the new system, since the fstab, /boot will be replaced with the backed-up ones?

As long as you used a Label for the partitions in the /etc/fstab you will be fine and it will continue to boot with the same Labels used on another drive. If you can use Labels in the Grub configuration instead of UUIDs then the same can work for the configuration with only a re-install to the drive. A fresh install of Grub would find the new UUIDs if you booted from rescue USB to chroot into the install to do it. No clue on snap never used it, all the rest can be left behind as it will be replaced when re-installed with your listing of its packages installed and you sync your backup of /etc or doing the following. An example of the Label idea I use on my Pi I simply backup the whole thing with an rsync command excluding the system temporary files (--exclude={/boot/firmware/*,/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found}). This would keep all your other installed files so the listing would not be needed to get the packages back.

You can see the PARTUUID= I used to use but got sick of changing them every time I backup the LABEL= solves that problem. Since the Pi does not use Grub to boot only specific named files it loads from the firmware partition it is so simple to back it up. rsync the / with the exclude line above used and the firmware partition to its partition on the backup drive shutdown switch drives and it boots the same OS as was on the drive you backed up. With a machine using Grub you need to boot from the already mentioned USB install/rescue drive and chroot into the install to re-install grub on the backup drive. It really is simple to do on regular machine once you get it into your head the only files that really matter to change are the Grub config files plus re-install of it and the fstab if not using a method that will survive the UUID problem if using them instead of LABEL=.

Edit: the /boot/firmware/* in the exclude line would not be needed on a regular machine.

It depends on the specific situation, but the easiest thing is to clone the entire partition so the UUID is the same. I'll actually clone the entire drive, including MBR, so it's ready to go. My usual procedure is:

1) Install both source and target drives

2) Boot up with USB thumbdrive

3) Use gparted to shrink source OS partition (I tend to use a single partition for the OS, including /boot)

4) Use dd to clone /dev/sda to /dev/sdb with count limit to reduce the time required

5) Use gparted to expand the OS partitions on both source and target

But lately, I have been doing new OS installs infrequently enough that I actually prefer to do a traditional install and then manually set things up. This takes longer, of course, but it keeps my basic skills refreshed.

Slightly more sophisticated is to use tune2fs to change the target boot partition's UUID to match what's expected by grub and fstab. This requires installing grub.

Both of these require you to be comfortable with multiple boot partitions out there with the same UUID. Basically, you generally do NOT want to install drives with such UUIDs on the same computer, or things could get confused badly. I'm okay with that, since I use these techniques mainly with laptops that can only have one internal drive anyway.

Of course, the more "correct" way to do things is to alter grub and fstab to reflect the new boot partitions (different) UUID. This isn't too hard once you know what you're doing and practice enough times.

Should work if you make certain to not overwrite the Grub configuration files and the /etc/fstab, /boot possibly depending on the files contained in it and if they have any UUIDs that would need to be changed.

Edit: and use rsync no sense copying files that do not need to be copied when a simple procedure will do it. Making certain you are up to date on all files before you sync on the backup and the OS versions are the same on both drives.

So basically, after copying my backup / to the new system, if I generate the fstab again using genfstab
and also run grub-mkconfig I will be fine?

Because I haven't used genfstab for some time, what partitions do I need to mound at /mnt before running the script?
1) Linux root ( / ) partition.
2) Windows partition for dual boot (if exists)
3) Home partition (if it's in a different partition)
4) EFI partition
Any other partitions which I want to be included in the fstab configuration file.

Is this correct?

Indeed the first time I did it with the LABEL= method now used I forgot and left the old drive connected in the backups place. It booted that as it found it first in the boot order I now backup over the network so I have no choice but to remove the drive to boot the backup drive I just did to confirm it works.

Do not need the genfstab really just use blkid to find the UUIDs of the partitions and simply replace them in the /etc/fstab on the backup drive, all your partitions used to boot the machine will already be in there just the UUIDs will point to the in use ones on the system drive not the backup drive.

I tried to backup my local computer and then restore it to a virtual machine with a cleaned install of Debian buster.

The backup command seems to work fine (the files where indeed copied to the /mnt/backups/debian directory):
But when I tried to restore the system in the virtual machine using (logged in as root):
It took an hour to complete, and then there were no files copied at all in the VM's filesystem!!!
I don't know what rsync was doing for an hour...

Does anyone have an idea of what went wrong?

By the way, when I installed Debian in the VM I used a different region/locale from my actual local computer.

"babaliaris" is not normally the root account name by default. Typically, a non-root account will not have access to all of the files and folders necessary.

The fact that you have "sudo" suggests to me that you are using an Ubuntu style install, with sudo configured and without a proper root login. But don't worry, you can at least locally log in as root via the command "sudo su -". That way, you can avoid the various problems with sudo.

I'm not sure how that would work with rsync, but the easiest solution might be to use an nfs share instead of invoking rsync's built in network capability.

I'm sorry, but sudo is more trouble than it's worth. It's a great tool for what it was originally intended for - providing limited elevated privileges so particular user groups or individual users could be permitted to execute certain specific commands that normally require elevated access (ideally still not root, but rather a service account with only the required elevated access capabilities).

But the thing Ubuntu uses it for? It causes a lot of confusion for no benefit.

As has been mentioned you are not logged as root but using sudo I always have real root account. The babaliaris will never have the permissions required to do a copy of root files. Put your machines ~/.ssh/id_rsa.pub contents, I would think it is the one used, into the VMs /root/.ssh/authorized_keys file to do a key based transfer of the files with root as the username for the transfer command. Make certain to backup the grub and fstab files of the VM before doing it to have copy to put back into place. Not sure it will work with the sudo involved.

Edit: Now I see it you would need to backup the locale file (/etc/default/locale) or dpkg-reconfigure locales after the copy to go back.

HA! I found the problem! It wasn't sudo, but that I was ssh-ing to the user "babaliaris" who is not the root user!
I was thinking "I use sudo, so it won't have permission problems" but that sudo is for my local machine no for babaliaris@192.168.42.221

So I did the following and it worked just fine:
Though the directory babaliaris@192.168.42.221:/mnt/backups/debian should be accessible by everyone since it was an external usb 3.0 drive but anyway.

Of course, I had to change /etc/ssh/sshd_config file to allow root login but anyway this is a small detail and has nothing to do with the backup.