1

I am using rsync to make a backup of Ubuntu running on a Raspberry Pi. I exclude all the usual directories whose contents are only created after boot up anyway.

The rsync writes to a backup image that I partition format and loop device mount and that image is written to an attached external USB drive. The data on the USB storage drive takes up a lot more space compared with the space it occupies on the source SD Card .. about 5325MB vs 3881MB.

Trying to Debug
I ran this rsync command to double check if some mysterious extra files were being created on the destination that are not on the source or were the same files getting bigger when they were on the destination compared with them on the source:

sudo rsync -nrlpgoDv --delete --exclude-from='/home/ubuntu/exclude-list.txt' / /mnt/dst_root/

But I don't see any big differences between the source and destination in terms of numbers of files or the size they occupy in source vs destination.

My Question
Why is this? Is it something to do with the Sector size?

Using fdisk -l my source Ubuntu OS has:

Disk /dev/mmcblk0: 29.54 GiB, 31719424000 bytes, 61952000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x12345678

Device         Boot  Start      End  Sectors  Size Id Type
/dev/mmcblk0p1 *      2048   526335   524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      526336 61951966 61425631 29.3G 83 Linux

I write the backup to an image file on the external storage drive. I partitioned the backup image like this:

echo "label: dos" | sfdisk "${IMGFILE}" > /dev/null
    sfdisk "${IMGFILE}" <<EOF > /dev/null
,256MiB,c
,+,83
EOF

I then format the root partition of that backup image file in a script like this:
mkfs.ext4 -q -b 4096 "${LOOP}p2" > /dev/null

Now fdisk on that loop device attached backup image gives:

Disk /dev/loop6: 5.62 GiB, 6035603456 bytes, 11788288 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x12345678

Device       Boot  Start      End  Sectors  Size Id Type
/dev/loop6p1        2048   526335   524288  256M  c W95 FAT32 (LBA)
/dev/loop6p2      526336 11788287 11261952  5.4G 83 Linux

fdisk -l on that external storage drive that the backup image is saved to:

Disk /dev/sda: 3.64 TiB, 4000752599040 bytes, 7813969920 sectors
Disk model: My Passport 2627
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: B5B6FD62-945C-466D-7T49-YU5D4RRE7087

Device     Start        End    Sectors  Size Type
/dev/sda1   2048 7813967871 7813965824  3.6T Linux filesystem

Is the data taking up more space on the USB drive because of differences in Sector Size vs I/O size maybe?

Separately my backup script tries to shrink down the root file system on the backup image using resize2fs (after the file system is unmounted). There are no errors but resize2fs does a really bad job of eliminating the free space in the backed up root file system. It never eliminates all the empty space and sometimes removes no empty space. Maybe this is also related to the sector size?

Update

After some investigation I think the issue might be related to - snap. It is installed in my Ubuntu system. From reading it looks like snap applications are stored in compressed squashfs file systems. Maybe when I rsync those they take up more space in the destination ext4 file system?

Any advice much appreciated!

8
  • 1
    writing to an image file that you then shrink seems... strange. Simply write a file archive: I don't like tar too much, but it gets the job done. If you need something cooler, mksquashfs can compress much better and can directly be mounted. May 28, 2022 at 21:24
  • I am modifying a script called image-backup in the Raspberry Pi image utilities thread. It backs up an OS running live on an SD Card in a Pi to an image file so that can easily be written back to the Pi using something like Balena etcher which is compatible with Linux and Windows so this approach is more portable and convenient than using tar. The shrinking of the partitions and file systems on the backup image is to keep the file size of the backup image small. May 29, 2022 at 0:27
  • Interesting that this script would "reinvent" squashfs worse! May 29, 2022 at 6:16
  • 1
  • 1
    @roaima I hear you... in fact my rsync command is really rsync -aDH ... I just used the -rlpgoDv options here for demonstration purposes anyway they are not important to the problem I was asking about. Cheers. May 31, 2022 at 21:32

1 Answer 1

0

The Answer
I was using rsync to do a full system backup from the SD Card running Ubuntu in the Pi to a sparse image file partitioned and formatted with a boot (fat32) and root (ext4) file system same as the sd card. My rsync command was copying the contents not only of /var/lib/snapd but also /snap. Turns out this was un-necessary.

Snap applications exist as squashfs images in /var/lib/snapd but are also mounted as read only file systems in /snap dir at boot time.

The rootfs in my backup image wasn't taking up more space than the rootfs in the running Ubuntu OS after all. The problem was I was using the df command to report the space occupied. The df command was the wrong choice because it doesn't include the size of mounted objects like the du command does.

This is the df command on the running Ubuntu Pi OS... It reports the space occupied by the rootfs as 3885MB.

ubuntu@ubuntu:~$ df -BMB
Filesystem     1MB-blocks      Used Available Use% Mounted on
tmpfs               398MB       5MB     393MB   2% /run
/dev/mmcblk0p2    31312MB    3885MB   26120MB  13% /
tmpfs              1988MB       0MB    1988MB   0% /dev/shm
tmpfs                 6MB       0MB       6MB   0% /run/lock
/dev/mmcblk0p1      265MB     155MB     110MB  59% /boot/firmware
/dev/sda1       3936879MB 1386199MB 2350626MB  38% /media/4TB1

Now I ran the du command in Ubuntu Pi OS running in the Pi and the reported space used in rootfs is 4.7GiB (5046MB) This is because it includes the space occupied by the mounted squashfs images in /snap. This is about the same as the amount of space the rootfs occupies in my backup image.

ubuntu@ubuntu:/usr/local/bin$ sudo du -hs /
du: cannot access '/proc/6297/task/6297/fd/4': No such file or directory
du: cannot access '/proc/6297/task/6297/fdinfo/4': No such file or directory
du: cannot access '/proc/6297/fd/3': No such file or directory
du: cannot access '/proc/6297/fdinfo/3': No such file or directory
4.7G    /

In contrast to this when I take the SD Card out of the Pi... This is the output of the du command run on the rootfs in the sd card connected to my laptop:

[flex@flex ~]$ sudo du -hs /media/writable/
3.3G    /media/writable/

This is because the snap applications are no longer mounted in the /snap dir in the sd card because it's not running Ubuntu OS in the Pi.

1
  • Oftentimes you may want to run du -x (or similar on other OSs) so that you are only summing up the stuff on one filesystem. Handy so you avoid summing up virtual filesystems like /proc or similar. That will also give you parity to df
    – BowlOfRed
    May 31, 2022 at 21:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .