How to backup before a release upgrade from Ubuntu 18.04.5 LTS server?

[Bo Berglund]

On Sun, 12 Sep 2021 09:27:29 +0200, Ralf Mardorf via ubuntu-users
<ubuntu-users at lists.ubuntu.com> wrote:

>On Sun, 12 Sep 2021 08:38:58 +0200, Bo Berglund wrote:
>>I have tried to figure out how but failed, most search hits talk about
>>setting up regular backup systems for the *data*, and they assume
>>there is a desktop too. But this is a headless server accessed via SSH
>>using PuTTY on Windows.
>
>Hi,
>
>actually it's you who missed to do the home work in the first place
>;). Do you have physical access to the server? If you are _not_ using a
>file system that allows to take snapshots from a running system, such
>as ext4 (it doesn't provide this feature)

The server is headless but sits under my desk connected to an UPS system for
24/7 operation.

So I have ext4 on sda1:

$ sudo lsblk -o UUID,NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,MODEL
UUID                  NAME   FSTYPE     SIZE MOUNTPOINT     LABEL MODEL
                      loop0  squashfs  99.4M /snap/core/11420
                      loop1  squashfs  99.4M /snap/core/11606
                      sda             465.8G                 Hitachi HDS72105
ec0e8708-8a6a-4bbf-.. +-sda1 ext4       464G /
                      +-sda2              1K
a77b40db-2377-4d25-.. +-sda5 swap       1.8G [SWAP]
                      sr0              1024M                  DVDRAM GH60N

And the disk is used so:

$ df -h
Filesystem                                Size  Used Avail Use% Mounted on
udev                                      839M     0  839M   0% /dev
tmpfs                                     175M  9.6M  165M   6% /run
/dev/sda1                                 457G  236G  199G  55% /
tmpfs                                     871M     0  871M   0% /dev/shm
tmpfs                                     5.0M     0  5.0M   0% /run/lock
tmpfs                                     871M     0  871M   0% /sys/fs/cgroup
/dev/loop0                                100M  100M     0 100% /snap/core/11420
/dev/loop1                                100M  100M     0 100% /snap/core/11606
192.168.119.138:/volume1/VIDEO/Backup/ubu 7.2T  5.0T  2.3T  70% /nfs/backup
192.168.119.138:/volume1/VIDEO/USA        7.2T  5.0T  2.3T  70% /nfs/nas
tmpfs                                     175M     0  175M   0% /run/user/1000

Of this the videos are located in /nome/bosse/www and comprise 198 GB, so
everything else sums up to 38GB of which SVN is 6 GB

>, the best approach is to shut
>down the server first. From another install or a live media (DVD, USB
>stick) you can backup the complete install. I'm doing this for my
>desktop machine all the time. 

I guess you mean to back up *everything* including the data on www and svn then?
That would take a lot of time and is only really valid for SVN in my case.
I am really not worried about disk failure but of Linux functionality failure
after the distro upgrade...

>However, assuming you can shut down the machine and e.g. insert an USB
>stick, then copy by running
>
>sudo cp -ai /mount_point_install/* /mount_point_backup_media/
>
>The "a" option is mandatory, the "i" option isn't.
>
>Alternatively just one tar example
>
>sudo tar --xattrs -czf /m_point_install/* /m_point_backup_med/bak.tar.gz
>

I have a lot of Raspberry Pi units and I am sometimes in need of a way to clone
installations. Here I have found a few systems that work towards an attached
second SD-card or even to an nfs share.

Two examples:
https://github.com/billw2/rpi-clone/blob/master/rpi-clone

This uses rsync rather than tar and makes a functional copy of the installation
SD card. It can be used as a backup solution since the SD card can be left in
place and the rsync based script run at a later time or by cron when it will
only transfer new files.
However, it is creating a multitude of files and it needs a file system target
which allows setting the permissions etc...

https://github.com/tom-2015/imgclone

This makes an image file that can be used to write on a different SDcard and is
a compiled program so is difficult to see what exactly it does.

So none of these approaches are really useful here...

Tar might be what is left since it as you say handles the permissions etc
internally and tar can be set to create a compressed archive in one go thus
making an nfs share possible to use as target.

I just have to figure out how to exclude certain directories from the backup.

And what happens with stuff that has been symlinked to two places like my www
dir, will it be copied from both places then making the archive twice as big?

And why the need to shut down the server and boot it with installation media?


-- 
Bo Berglund
Developer in Sweden