backing up a PI SD card..

Raspberry -> Accessories -> SD Card Copier

What has a raspberry to do with this?

"The Natural Philosopher" snipped-for-privacy@invalid.invalid wrote

| > Raspberry -> Accessories -> SD Card Copier | >

| What has a raspberry to do with this? | Start menu. The raspberry icon in lower left. You didn't say which Pi you have, so you may not have that icon or the copier software.

??? Icon? On a headless Pi Zero?

Pi Zero

"The Natural Philosopher" snipped-for-privacy@invalid.invalid wrote

| > | | > Start menu. The raspberry icon in lower left. | | ??? Icon? On a headless Pi Zero? | Ah. You might have said that in the first place. It doesn't make much sense to ask for help and then be difficult with people who try to help. I gather you only posted to argue.

No. I am trying to establish whether one can, in essence, make a bootable PI SD card by taking a raw card, creating the two partitions on it and loading it up with files, or whether there is the equivalent of a boot sector which would mandate the use of e.g. dd to create it

Naturally all the documentation assumes a windows numpty and shows you how to stamp the SD card with an image.

You assumed I wanted to clone the card. I don't. I want to back one up without using DD because, as the concurrent thread has identified, the PI expands the file system to the whole card and that makes for a big image. I'd rather back it up as files if possible.

If at some future date I need to recreate it, instead of dd-ing the image, I would prefer to create the two partitions and populate them from the tarball.

Yes. In fact if you set the OS up from scratch you don't even need two partitions, just one FAT32 parition with the boot files required by the Pi.

I set up a Linux system to boot off the FAT32 parition then run in a tmpfs. So instead of an image file there's just a ZIP archive which needs to be unpacked to the root of a FAT32-formatted SD card. No image writer tool required, and no worries about partition sizes.

The Pi doesn't need anything like a boot sector. The firmware is smart enough to find the boot files on the filesystem, provided it's FAT32.

I suppose that needs to be the first partition? The other question why always gets me on backups is how many of the directories in the root partition can safely be ignored?

/sys, /proc, /run would seem to be created by the machine at boot time, and shouldn't be created as subdirs of the root partition...or should the directories be created, but empty?

So putatively one might back up everything in / except /run, /proc & /sys, including /boot, plonk a shiny new SD card in a host computer, create a VFAT partition of say 256MB, and the rest as ext4, untar the archive into the ext4 partition and move the entire contents of /boot onto the VFAT, shove the card in a pi , apply power, and Robert should be a relative?

The vfat partition will get mounted on the (now empty) /boot mount point, and everything else will be where it ought to be, and /run /sys and /proc will get generated by the boot process?

What about /dev? Is that dynamically created or not?

Take a look at 'rsync' - its my go-to tool for backing up complete Linux filing systems, specific partitions or lists of files and partitions to as a named directory structure on a backup disk.

It is designed make the backup directory structure identical to the current list of files and directories you ask it to back up, IOW, if you rerun the sa,me command a week later it will remove any files and directories from the previous backup session, replace any files and directories that have been changed and add any new files and directories.

Consequently, subsequent runs will usually be much faster than the initial backup.

Want to keep older backups? Just use a cycle of backup files. SD-cards or USB-connected disks: I back up entire Linux file systems to a cycle of two

Retrieving whole partition contents, directories and/or files from these backups is simple: simply mount the backup volume and copy anything you've lost back to where it should be on your computer's filing system.

rsync manuals and software are in included in most mainstream Linux distros. HTH

Nope: just whatever partition the RPi installer configured to be the boot partition.

Just tell dd to copy everything from the source SD card to the new one. If the latter card is bigger,use parted to extend the new ext4 partition and to format the new sectors.

Here's the rsync options I used to backup the partitions, firstly the FAT partition which accounts for the lower resolution of timestamps

rsync -vax --stats --modify-window=2 --delete /boot/ <boot_backup_dir>

And the main partition with the exclusions to prevent pseudo filing systems and temporary stuff being included when backing up live systems, some of it shouldn't be necessary but turns out is needed

rsync -vaxHAX --stats --numeric-ids --delete --delete-excluded

--exclude=/tmp/*

--exclude=/run/*

--include=/var/lock

--exclude=/var/run

--exclude=/var/swap

--exclude=/var/cache/*

--exclude=/var/tmp/*

--exclude=/var/lib/machines/*/var/cache/

--exclude=/var/lib/mlocate/*

--exclude=/var/lib/nginx/fastcgi/*

--exclude=/var/log/journal/*

--exclude=/var/log/Xorg.*

--exclude=/lost+found/*

--exclude=*/.cache

--exclude=*/__pycache__

--exclude=*/chromium/hyphen-data/

--exclude=*/.config/chromium/*Cache*/* / <root_backup_dir>

---druck

/sys, /proc and /dev are filesystems which are mounted at boot time. You need the empty directories to act as mount points, because Unix mounts filesystems on top of a directory that already exists, switching out whatever is there.

It seems that some distros have /var/run and point a symlink from /run to it, so it doesn't need a mount point created for them. They then mount a tmpfs at /var/run (so /var/run is an empty directory that needs to exist to be mounted on top of)

I think that will probably work.

One thing to watch that distros' /etc/fstab often mounts partitions based on a UUID. So /boot on one SD will have a different UUID to another, and the mount of /boot will fail. It'll still find the kernel from /boot, but any time later anything wants to load something from /boot it may fail because the mount failed. You could change the device name in /etc/fstab to be /dev/mmcblk0p1 or similar to be sure it's the same every time. (the Pi has a single SD slot so no chance of mixing it up with another)

'blkid' will show your partition devices with their UUIDs.

A dynamic filesystem mounted to a static pre-existing mount point.

Theo

"It is no longer necessary for the first partition to be the FAT partition, as the MSD boot will continue to search for a FAT partition beyond the first one."

/sys and /proc can be created empty, because they're mountpoints. However I don't bother excluding them from backups personally.

Yes. Mounting the FAT32 partition at /boot is specific behaviour for RPi OS / Debian. Linux itself doesn't care if that partition gets mounted at all - by the time the kernel is loaded its job has been done, but Debian probably expects it there for configuration and upgrades.

The device files need backing up, or else something might have to create them with mknod. It contains more mountpoints though, so you can look at the list displayed by "mount" and exclude those sub-directories of /dev if you like. Again, I don't bother to do that.

Been using it for years to do nightly backups of all my data.

They are. When I replaced my backup drive because it went faulty the machine ran all night filling it up :-)

Mostly its about a 3 minute run.

However this isn't about backup, so much as recovering from an SD card failure.

No data on this machine ever changes - unless its reprogrammed at a user level, and that is easy to replicate in half an hour

I probably wouldn't ever bother to update or upgrade its operating system either. It will sit there, 'bits in silicon' , just doing the one thing it was designed to do until I move into a gaga home because I cant remember who I am :-)

I think we are not on the same hymn sheet.. The point is to NOT use a 'pi installer'

That is precisely what I do not want to do, and what this thread is all about, because DD is simply too blunt an instrument.

Looks very like what my *86 big main server has..but that is a handy crib and thank you very much for it.

I'll have to look at comms between my main backup machine and the pi, but that may after all be the simplest solution

Good...Well at least we dont have to flirt with 'secure boot' and all the other trash that comes with a *86 board. Nice old school 'put this here, and the boot loader will find it and boot it'

I knew i had forgotten something..

from the pis /etc/fstab

proc /proc proc defaults 0 0 PARTUUID=b8c9fbb7-01 /boot vfat defaults 0 2 PARTUUID=b8c9fbb7-02 / ext4 defaults,noatime 0 1

Yeah. Easy enough to either label a new card with the old ids or modify fstab.

BTDTGTTS

OK, thanks

Only question left unanswered is whether there is anything else on the SD cardstructure to identify which partition is the boot one?

Does the boot loader simply look for the only (first?) VFAT partition?

Ah. The Final Question is answered.

Thanks m8

One presumes that if anything else is recreated in /dev at boot, it will wipe out or be mounted over what was 'backed up'.

Well the strategy seems clear: At some point I will set up a 'preserve this SD card' methodology, buy a new SD card and see if I can make it work.

Am 17.09.23 um 11:19 schrieb The Natural Philosopher:

Using an other Linux computer ( raspberry pi 400 or PC ), take an 5 TB hard disk, an use dd in order to copy the SD card. This may be enough for 300 different copy 16 GB SD card.