Destination: does it have to be as big as the RPI SD card?

[paolotremadio]

Hi,

I have a 64gb SD card in my RPI with just 5gb in use. I also have an USB memory stick attached of 16gb (pretty much all free).

# df -h
/dev/root        57G  5.0G   49G  10% /
devtmpfs        458M     0  458M   0% /dev
tmpfs           462M     0  462M   0% /dev/shm
tmpfs           462M   13M  450M   3% /run
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
tmpfs           462M     0  462M   0% /sys/fs/cgroup
/dev/mmcblk0p6   66M   24M   43M  36% /boot
tmpfs            93M  8.0K   93M   1% /run/user/1000
/dev/mmcblk0p5   30M  801K   27M   3% /media/pi/SETTINGS
/dev/sdb1        15G   44M   14G   1% /media/sd

When I try to run /apps/bkup_rpimage/bkup_rpimage.sh start -c /media/sd/rpi.img, this is what happens:

Starting SD Image backup process
Creating sparse /media/sd/rpi.img, the apparent size of /dev/mmcblk0
0+0 records in
0+0 records out
0 bytes copied, 0.00106547 s, 0.0 kB/s
Attaching /media/sd/rpi.img to /dev/loop0
Copying partition table from /dev/mmcblk0 to /dev/loop0
Checking that no-one is using this disk right now ... OK

Disk /dev/loop0: 59.6 GiB, 64021856256 bytes, 125042688 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: 0x095a474a

Old situation:

>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0x0001a4b4.
/dev/loop0p1: Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 1.6 GiB.
/dev/loop0p2: Created a new partition 2 of type 'Extended' and of size 58.1 GiB.
/dev/loop0p3: Created a new partition 5 of type 'Linux' and of size 32 MiB.
/dev/loop0p6: Created a new partition 6 of type 'W95 FAT16 (LBA)' and of size 66 MiB.
/dev/loop0p7: Created a new partition 7 of type 'Linux' and of size 58 GiB.
/dev/loop0p8: Done.

New situation:

Device       Boot   Start       End   Sectors  Size Id Type
/dev/loop0p1         8192   3300781   3292590  1.6G  c W95 FAT32 (LBA)
/dev/loop0p2      3300782 125042687 121741906 58.1G  5 Extended
/dev/loop0p5      3301376   3366909     65534   32M 83 Linux
/dev/loop0p6      3366912   3502079    135168   66M  e W95 FAT16 (LBA)
/dev/loop0p7      3506176 125042687 121536512   58G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Invalid argument
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
Syncing disks.
Formatting partitions
mkfs.fat 4.1 (2017-01-24)
mke2fs 1.43.4 (31-Jan-2017)
Found a dos partition table in /dev/loop0p2
Proceed anyway? (y,N) y
mkfs.ext4: inode_size (128) * inodes_count (0) too big for a
	filesystem with 0 blocks, specify higher inode_ratio (-i)
	or lower inode count (-N).

Mounting /dev/loop0p1 and /dev/loop0p2 to /mnt/rpi.img/
mount: /dev/loop0p2: can't read superblock
Skipping rsync since /mnt/rpi.img/ is not a mount point
Flushing to disk
Unmounting /dev/loop0p1 and /dev/loop0p2 from /mnt/rpi.img/
umount: /mnt/rpi.img/: not mounted
rmdir: failed to remove '/mnt/rpi.img/': Directory not empty
Detaching /media/sd/rpi.img from /dev/loop0
SD Image backup process completed.

Any clue about how to fix this issue?

[lzkelley]

Not really, sorry; I don't know much about this stuff. If the backup drive has more free space than is in usage on the pi then it seems like it should be fine... it's a direct transfer so it shouldn't take up any additional space.

It looks like there are at least two possible issues: 1) the partition table is a bad format (dos/fat) that it doesn't like, and 2) it's having trouble mounting to /mnt/rpi.img/ ... Good luck. If you figure it out, please post pack in case it helps someone else in the future!

[dolorosus]

The imagesize can be reduced, the backup has to fit into the image, that will be sufficiant. The last recent verion has an -s option which will allow you to set the size of the image file.

bkup_rpimage start -c -s 8000 /backupimagefile

will create a imagefile of 8000m. and perform the backup. It will NOT be checked if the backup will fit into the image! As a rule of thumb you should give additional 1000m to the information from df -m to be safe.

On the other hand: the imagefile is a sparse file, so the size is only relevant if the file is copied to a filesystem not supporting sparse files.