On Mon, 07 Dec 2020 00:32:29 +0000, druck wrote:

> You shouldn't be backing up files under /boot, the boot partition needs
> to be backed up separately.
>
Quite agree!

However, a simplistic backup run on an RPi that writes '/*' to a .tgz
archive or uses rsync to make a full filesystem backup to a different SD
card or USB disk will do exactly that.

Its very easily done and, at first glance, looks like a neat trick.

A somewhat  more knowledgeable person may make a TGZ archive of '/' plus
a zip backup of the boot partition. This also looks like a neat trick,
but also hides a similar problem.

All I'm trying to do is to explain the pitfalls in both backups and how
to fix them should these be the perp's only backups.

Bottom line: if you want to copy a working RPi system to a new SD card,
specially if you want a bigger filing system, don't mess with archivers,
go straight for the jugular and use Clonezilla.


> Most backup software will not cross filing system boundaries, so you
> don't backup several TB of mounted NAS drives rather than just your SD
> card. If rolling your own backups, make sure you specify option not to
> follow mounts or links to other filing systems.
>
Indeed, but this us a special case: the RPi boot process mounts the boot
partition on /boot and any backup of '/' made on a running RPi with rsync
*will* include the contents of the boot partition unless you've
configured the rsync run to exclude /boot/* . Don't ask me how I know!

If this is something you do all the time you'll know it already: a friend
is like this he's constantly setting up RPis for people who like music
and has the parameters engraved on his brain. I, like most of us only do
this stuff as long intervals and so, for us, that's why I'm saying that
using CloneZilla is pretty much a one stop shop if you only have to
transfer an RPi filesystem to an new SD card every few years.

NOTE: I didn't run out of space on mt EXT file system: I was only kicked
into making the SD card switch because RPiHQ decided it would be a good
idea to put copies of all bootable kernels in everybody's boot partition,
which had the unintended consequence of overflowing my boot partition
when the update tried to install an new, bigger kernel set.


> --druck





--
--
Martin    | martin at
Gregorie  | gregorie dot org

--- SoupGate-Win32 v1.05