Pisafe stalls on reading sdcard. about pi-safe HOT 16 CLOSED

Hello Cury,
I went ahead and reloaded V1.1.1 to the github. Follow the std install instructions, but change the filename from pisafe to pisafe_1.1.1

I would very much like to better understand what when wrong with 1.2.5 and fix it. Thanks for all the details. I wonder if "pv" is not working right. That is what gives you the progress bar.

1. Did you run "pisafe install"?
2. Are you running pisafe with the menu or CLI?
3. Can you set debug mode to OFF?
4. Here is my screen:

PiSafe 1.2.5 f
Checking for PiSafe updates...
PiSafe 1.2.5 f Backup...
No extension specified. Adding '.img.zip'
OUT-FILE='/home/pi/Downloads/2022-04-11-pisafe.img.zip'
7.40gb to read from '/dev/sda'
18.8gb available space on '/home/pi/Downloads'

~ PiSafe 1.2.5 f Backup '/dev/sda' to '/home/pi/Downloads/2022-04-11-pisafe.img.zip'
~ Step 1 of 3 - Copying '/dev/sda' to '/home/pi/Downloads/2022-04-11-pisafe.img' ...
Mon 11 Apr 2022 01:28:28 PM EDT
Media size=7.40gb
Skipping 1.00mb of freespace at end of media.
Reading 7.40gb...
~ Running: sudo pv /dev/sda -p -s 7947157504 | sudo dd bs=4194304 of='/home/pi/Downloads/2022-04-11-pisafe.img' count=1895 iflag=fullblock conv=fsync
[=> ] 2%

Peace,

from pi-safe.

Hi Richard,

Thanks for your very fast answer.

What "pv" means??? Package???

Your questions:

1 Did you run "pisafe install"?
Yes, like your instructions
(wget https://raw.githubusercontent.com/RichardMidnight/pi-safe/main/pisafe -O pisafe
bash pisafe install)

2 Are you running pisafe with the menu or CLI?
Yes.

3 Can you set debug mode to OFF?
Yes, but later at night.

Thanks for this great tool.

from pi-safe.

pv is a linux CLI tool called Pipe Viewer. It gives you a visual of data moving from one program to another. It is what displays the "progress bar".

You could try using the pisafe menu. It helps create correct syntax.

I will have to try to replicate your configuration and see if I get the same problem.

from pi-safe.

Hi there,

My minutes of happiness took to short... LOL...

After:

wget https://raw.githubusercontent.com/RichardMidnight/pi-safe/main/pisafe -O pisafe_1.1.1

I got this output:

pi@pisafe-bullseye:~ $ bash pisafe_1.1.1 install
PiSafe 1.2.5
Checking for PiSafe updates...
PiSafe: INSTALL: Install PiSafe 1.2.5? [y/n]?
PiSafe NOTICE: ~ PiSafe not installed
pi@pisafe-bullseye:~ $

Just like me, an old retired man, always looking for something new.

Thinking about the differences between our Systems.

PISafe 1.2.5 works for you, but not me, yes or not???

I'm using Raspberry PI 4 (8 and 4 GB) and you???

I'm using RPI OS (Bullseye, Buster (only to test Pisafe)) and Ubuntu 222.04, and you???

The differences are time zone (GMT -3), language (PT-BR), keyboard and mouse.

But these difs are not relevant for these different behaviors.

I want to challenge you, and you will reproduce the error.

Pick up a spare SDCard, install RPI OS Buster Legacy or Bullseye 2022-04-04 run apt update and dist-upgrade... and then install Pisafe 1.2.5. That's what I did on last sunday.

Thats all for today.

Cheers

from pi-safe.

Sorry.. try this:
wget https://raw.githubusercontent.com/RichardMidnight/pi-safe/main/pisafe_1.1.1 -O pisafe
bash pisafe install

from pi-safe.

Hi Richard,

Voila... Pisafe 1.1.1 is back and working.

Running on RPIOS bullseye:

/usr/local/bin/pisafe: linha 827: [: Disp.: esperava expressão de número inteiro
/usr/local/bin/pisafe: linha 838: [: Disp.: esperava expressão de número inteiro
No extension specified. Adding '.img.zip'
OUT-FILE='/media/cury/cacarec0/2022-04-12-ub2204nosnap.img.zip'
Starting PiSafe 1.1.1 Backup...
IN-DEV='/dev/sdb'
OUT-FILE='/media/cury/cacarec0/2022-04-12-ub2204nosnap.img.zip'
Compression set to level 5 of 9
Step 1 of 3 - Reading '/dev/sdb' to '/media/cury/cacarec0/2022-04-12-ub2204nosnap.img' ...
ter 12 abr 2022 14:06:55 -03
29.7gb to read
29,7GiB 0:23:00 [22,0MiB/s] [==============================================================>] 100%
0+486984 registros de entrada
0+486984 registros de saída
31914983424 bytes (32 GB, 30 GiB) copiados, 1394,98 s, 22,9 MB/s
Done reading SD card
'30G /media/cury/cacarec0/2022-04-12-ub2204nosnap.img'
Step 1 took 23 min 20 sec

Step 2 of 3 - Shrinking filesystem with PiShrink ...
[sudo] senha para cury:
pishrink.sh v0.1.2
pishrink.sh: Gathering data ...
pishrink.sh: Checking filesystem ...
writable: 209300/1929536 files (0.2% non-contiguous), 1943623/7725947 blocks
resize2fs 1.46.2 (28-Feb-2021)
pishrink.sh: Shrinking filesystem ...
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/loop0 to 2062543 (4k) blocks.
Begin pass 2 (max = 642694)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 236)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 20175)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop0 is now 2062543 (4k) blocks long.

pishrink.sh: Shrinking image ...
pishrink.sh: Shrunk /media/cury/cacarec0/2022-04-12-ub2204nosnap.img from 30G to 8.2G ...
Done shrinking filesystem
'8,2G /media/cury/cacarec0/2022-04-12-ub2204nosnap.img'
Step 2 took 6 min 52 sec

Step 3 of 3 - Compressing '/media/cury/cacarec0/2022-04-12-ub2204nosnap.img' to '/media/cury/cacarec0/2022-04-12-ub2204nosnap.img.zip' ...
ter 12 abr 2022 14:37:07 -03
Compression set to level 5 of 9
8.11gb to compress.
Each dot=166 MB
/media/cury/cacarec0/2022-04-12-ub2204nosnap.img.........20........40........60........80........100%
[ 0/8.1G] adding: media/cury/cacarec0/2022-04-12-ub2204nosnap.img .................................................. (deflated 64%)
Done compressing '/media/cury/cacarec0/2022-04-12-ub2204nosnap.img' to '/media/cury/cacarec0/2022-04-12-ub2204nosnap.img.zip'
3,0G /media/cury/cacarec0/2022-04-12-ub2204nosnap.img.zip
Step 3 took 12 min 19 sec
/usr/local/bin/pisafe, linha 430: 6290 Morto speaker-test -t sign -f 700 > /dev/null
Backup done. '/dev/sdb' backed up to '/media/cury/cacarec0/2022-04-12-ub2204nosnap.img.zip' in 42 min 31 sec.
Debug_mode=on
Exit_code=0
Press any key to continue...
``
Now we can see progress bar when reading.

Restore not tested.

My challenge is on.

Pisafe 1.2.5 may have a missing packet or a version compatibility problem.

When installing on Ubuntu 22.04 I'm facing this msg:

lua is a virtual packet:
lua5.4 5.4.4-1
lua5.3 5.3.6-1build1
lua5.2 5.2.4-2
lua5.1 5.1.5-8.1build4
You must select one from list to install.

E: 'lua' packet was not installed.

May I choose any one?

Now it is up to you.

Thanks for helping,

from pi-safe.

Glad pisafe 1.1.1 it is working for you.
The new version of PiSafe does not use lua because it is a pain to install. For Pisafe_1.1.1, try installing lua newest to oldest until it works.

from pi-safe.

Hello Cury,
From your first post, Your screen shows it makes it to estimating the size of the "source media". See your line
- 29.7gb to read from '/dev/mmcblk0'
but does not get to confirming there is room on the "destination drive". See my lines
- 7.40gb to read from '/dev/sda'
- 18.8gb available space on '/home/pi/Downloads'
So it seems there is a problem with it estimating the available space on the "destination drive"
I wonder if there is a problem with your naming of your "destination drive". You can try running it with the PiSafe menu.
Note: the screen log in Pisafe 1.1.1 is different than in 1.2.5.

However, I have not been able to reproduce your error.
Using a Pi 4 with 8GB
I installed Bullseye 64 (brand new) on a Samsung USB stick and booted from it.
I installed PiSafe 1.2.5
I inserted an mmc into the slot
I started pisafe from the menu, selected backup, picked the mmc device, left the name default and started the backup.
It worked fine.
Then I tried it from a command line and it worked fine.

• pisafe backup /dev/mmcblk0 pisafebackup

I will post the screen log soon.

from pi-safe.

pi@raspberrypi:~ $ pisafe backup /dev/mmcblk0 pisafebackup
PiSafe 1.2.5
Checking for PiSafe updates...
PiSafe 1.2.5 Backup...
No extension specified. Adding '.img.zip'
OUT-FILE='pisafebackup.img.zip'
1.17gb to read from '/dev/mmcblk0'
23.5gb available space on '.'
PiSafe: BACKUP: Backup ' - 7.4G (/dev/mmcblk0)' to 'pisafebackup.img.zip' now? [y/n]?
~ PiSafe 1.2.5 Backup '/dev/mmcblk0' to 'pisafebackup.img.zip'
~ Step 1 of 3 - Copying '/dev/mmcblk0' to './pisafebackup.img' ...
Thu 14 Apr 2022 11:44:31 AM EDT
Media size=7.40gb
Skipping 6.22gb of freespace at end of media.
Reading 1.17gb...
~ Running: sudo pv /dev/mmcblk0 -p -s 1259339776 | sudo dd bs=4194304 of='./pisafebackup.img' count=301 iflag=fullblock conv=fsync
301+0 records in======================================================================================================> ] 99%
301+0 records out
1262485504 bytes (1.3 GB, 1.2 GiB) copied, 68.1586 s, 18.5 MB/s
[======================================================================================================================>] 100%
Done copying media '/dev/mmcblk0'
'1.2G ./pisafebackup.img'
Step 1 took 1 min 13 sec

~ Step 2 of 3 - Shrinking filesystem ...
~ Running: sudo pishrink.sh './pisafebackup.img'
pishrink.sh v0.1.2
pishrink.sh: Gathering data ...
tune2fs: Bad magic number in super-block while trying to open /dev/loop0
tune2fs 1.46.2 (28-Feb-2021)
/dev/loop0 contains a vfat file system labelled 'ubuntu-seed'
pishrink.sh: ERROR occurred in line 297: tune2fs failed. Unable to shrink this type of image
~ Exit_Status 7 running 'sudo pishrink.sh './pisafebackup.img' '
~ Continuing without shrinking the file system...
Done shrinking filesystem.
'1.2G ./pisafebackup.img'
Step 2 took 0 min 6 sec

~ Step 3 of 3 - Compressing './pisafebackup.img' to 'pisafebackup.img.zip' ...
Thu 14 Apr 2022 11:45:50 AM EDT
Compression set to level 1 of 9
1.17gb to compress.
Each dot=24m
./pisafebackup.img [........................|.........................] 100%
~ Running: zip -dbds 24m -m -1 'pisafebackup.img.zip' './pisafebackup.img'
[ 0/1.1G] adding: pisafebackup.img .................................................. (deflated 69%)
Done compressing './pisafebackup.img' to 'pisafebackup.img.zip'
369M pisafebackup.img.zip
Step 3 took 0 min 46 sec
PiSafe BACKUP: ~ Backup complete.
' - 7.4G (/dev/mmcblk0)' backed up to
'pisafebackup.img.zip'
7.40gb reduced to 368mb in 2 min 5 sec.
pi@raspberrypi:~ $

from pi-safe.

Hi Richard,

Let me explain:

I was using, at that time, a Samsung USB Bar 128Gb Formated like this:

/dev/sdb1 253M 31M 222M 12% /media/vieira/boot
/dev/sdb2 24G 9,1G 14G 41% /media/vieira/rootfs
/dev/sdb6 92G 11G 76G 13% /media/vieira/BKP1

And as you can see in my first post I was placing bkp file in this last partiion:

OUT-FILE='/media/pi/BKP1/PISafe/2022-04-10-ub2204nosnap.img.zip'

This way I'm sure there was room for resulting file.

But I was not sure if the process could allocate temp files on rootfs.

And more, Pisafe_1.1.1 worked in this configuration.

But I expended all afternoon making more tests an I have a conclusion, something I could never imagine.

Dont miss next post...

Bye from Brazil,

from pi-safe.

Hi Richard,

I was thinking your post about my challenge, and became very sad because it didn't reproduce the error.

So I acepted my own challenge:

I installed Bullseye 64 (2022-04-04) on a Samsung USB stick 128 Gb and booted from it and installed PiSafe 1.2.5
and it did not worked.

I resized USB Bar, Using gparted, to have a big root partition,
and it did not worked.

Thinking... Thinking... What are the diferences between our installations...

Then I decided to install the same Bullseye 64 (2022-04-04) on the Samsung USB Bar 128 Gb but this time not changing language (keeping EN-GB) and keeping time zone and Keyb.

Now it WORKS.

~ Backup complete.
│ ' - 29.7G (/dev/mmcblk0)' backed up to
│ '/home/pi/Downloads/2022-04-14-test3.img.zip'
│ 29.7gb reduced to 3.01gb in 29 min 41 sec.
│

pi@raspberrypi:~ $ bash pisafe
PiSafe 1.2.5
Checking for PiSafe updates...
PiSafe 1.2.5 Backup...
No extension specified. Adding '.img.zip'
OUT-FILE='/home/pi/Downloads/2022-04-14-test3.img.zip'
29.7gb to read from '/dev/mmcblk0'
109gb available space on '/home/pi/Downloads'

~ PiSafe 1.2.5 Backup '/dev/mmcblk0' to '/home/pi/Downloads/2022-04-14-test3.img.zip'
~ Step 1 of 3 - Copying '/dev/mmcblk0' to '/home/pi/Downloads/2022-04-14-test3.img' ...
Thu 14 Apr 21:51:03 BST 2022
Media size=29.7gb
Skipping 16.5kb of freespace at end of media.
Reading 29.7gb...
~ Running: sudo pv /dev/mmcblk0 -p -s 31914966528 | sudo dd bs=4194304 of='/home/pi/Downloads/2022-04-14-test3.img' count=7610 iflag=fullblock conv=fsync
[========================================================================>] 100%
7609+1 records in
7609+1 records out
31914983424 bytes (32 GB, 30 GiB) copied, 855.176 s, 37.3 MB/s
Done copying media '/dev/mmcblk0'
'30G /home/pi/Downloads/2022-04-14-test3.img'
Step 1 took 14 min 21 sec

~ Step 2 of 3 - Shrinking filesystem ...
~ Running: sudo pishrink.sh '/home/pi/Downloads/2022-04-14-test3.img'
pishrink.sh v0.1.2
pishrink.sh: Gathering data ...
pishrink.sh: Checking filesystem ...
writable: 209866/1929536 files (0.2% non-contiguous), 1970730/7725947 blocks
resize2fs 1.46.2 (28-Feb-2021)
pishrink.sh: Shrinking filesystem ...
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/loop0 to 2089596 (4k) blocks.
Begin pass 2 (max = 629309)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 236)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 20275)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop0 is now 2089596 (4k) blocks long.

pishrink.sh: Shrinking image ...
pishrink.sh: Shrunk /home/pi/Downloads/2022-04-14-test3.img from 30G to 8.3G ...
Done shrinking filesystem.
'8.3G /home/pi/Downloads/2022-04-14-test3.img'
Step 2 took 4 min 38 sec

~ Step 3 of 3 - Compressing '/home/pi/Downloads/2022-04-14-test3.img' to '/home/pi/Downloads/2022-04-14-test3.img.zip' ...
Thu 14 Apr 22:10:02 BST 2022
Compression set to level 1 of 9
8.22gb to compress.
Each dot=168m
/home/pi/Downloads/2022-04-14-test3.img [........................|.........................] 100%
~ Running: zip -dbds 168m -m -1 '/home/pi/Downloads/2022-04-14-test3.img.zip' '/home/pi/Downloads/2022-04-14-test3.img'
[ 0/8.2G] adding: home/pi/Downloads/2022-04-14-test3.img .................................................. (deflated 63%)
Done compressing '/home/pi/Downloads/2022-04-14-test3.img' to '/home/pi/Downloads/2022-04-14-test3.img.zip'
3.1G /home/pi/Downloads/2022-04-14-test3.img.zip
Step 3 took 10 min 42 sec
Press any key to return

pi@raspberrypi:~ $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 118G 3.3G 110G 3% /
devtmpfs 3.7G 0 3.7G 0% /dev
tmpfs 3.9G 0 3.9G 0% /dev/shm
tmpfs 1.6G 1.4M 1.6G 1% /run
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
/dev/sda1 253M 31M 222M 12% /boot
tmpfs 782M 32K 782M 1% /run/user/1000
/dev/mmcblk0p2 29G 7.0G 21G 26% /media/pi/writable
/dev/mmcblk0p1 253M 114M 139M 46% /media/pi/system-boot

Now changed lang to PT-BR and rebooted.

PiSafe 1.2.5
Checking for PiSafe updates...
PiSafe 1.2.5 Backup...
No extension specified. Adding '.img.zip'
OUT-FILE='/home/pi/Downloads/2022-04-14-test5.img.zip'
29.7gb to read from '/dev/mmcblk0'

Stalled..........................................................

Back to EN-GB

pi@raspberrypi:~ $ bash pisafe
PiSafe 1.2.5
Checking for PiSafe updates...
PiSafe 1.2.5 Backup...
No extension specified. Adding '.img.zip'
OUT-FILE='/home/pi/Downloads/2022-04-14-test6.img.zip'
29.7gb to read from '/dev/mmcblk0'
101gb available space on '/home/pi/Downloads'

~ PiSafe 1.2.5 Backup '/dev/mmcblk0' to '/home/pi/Downloads/2022-04-14-test6.img.zip'
~ Step 1 of 3 - Copying '/dev/mmcblk0' to '/home/pi/Downloads/2022-04-14-test6.img' ...
Thu 14 Apr 22:46:44 BST 2022
Media size=29.7gb
Skipping 16.5kb of freespace at end of media.
Reading 29.7gb...
~ Running: sudo pv /dev/mmcblk0 -p -s 31914966528 | sudo dd bs=4194304 of='/home/pi/Downloads/2022-04-14-test6.img' count=7610 iflag=fullblock conv=fsync
[> ] 1%

I couldn't imagine that behavior....

If you still have that stick please use "sudo raspi-config" and change language to Brazilian Portuguese and keyb PT-BR,

And I don't know it relates or not to the error, change time zone to America - Sao Paulo.

Don't be afraid, only some messages will be translated, You can return to EN-US any time after test.

reboot and test again...

Too late in the night, I'm going to bad.

See you,

from pi-safe.

Great, you figured it out. I was able to reproduce your results!

eVisitor is expecting a result from the OS to be in English, and it came back in Portuguese!
I made a change to the beta version that should resolve the issue.
Can you try the beta ver as described on the github? It should be "ver 1.2.5 i"

Thanks for all your work on identifying the issue!

Richard.

from pi-safe.

Hi Richard,

This is a true collaborative work.

At last BKP started

pi@raspberrypi:~ $ pisafe
PiSafe 1.2.5 i
Checking for PiSafe updates...
PiSafe 1.2.5 i Backup...
No extension specified. Adding '.img.zip'
OUT-FILE='/home/pi/Downloads/2022-04-15-test9.img.zip'
29.7gb to read from '/dev/sdb'
92.8gb available space on '/home/pi/Downloads'

~ PiSafe 1.2.5 i Backup '/dev/sdb' to '/home/pi/Downloads/2022-04-15-test9.img.zip'
~ Step 1 of 3 - Copying '/dev/sdb' to '/home/pi/Downloads/2022-04-15-test9.img' ...
sex 15 abr 2022 15:40:36 -03
Media size=29.7gb
Skipping 16.5kb of freespace at end of media.
Reading 29.7gb...
~ Running: sudo pv /dev/sdb -p -s 31914966528 | sudo dd bs=4194304 of='/home/pi/Downloads/2022-04-15-test9.img' count=7610 iflag=fullblock conv=fsync
[==========>
^c

Now I will make same restore tests cause last week I had a a problem restoring an Ubuntu installation.

I would like if you could include an option for sound=on/off, cause in my sound bar, these BIPs often scares me.

Sorry about English mistakes.

Thanks for your work in this incredible tool.

See you later,

Cury

from pi-safe.

Terrific! Yes, please check the restore and let me know how it goes. You can restore with PiSafe or Imager or probably any other image writer.
Note: Even if step 2 of 3 says it cannot shrink the filesystem, the backup should still work. PiSafe can only shrink the filesystem if the last partition is of type ext4. Some distributions put a swap partition at the end of the drive, then it cannot be shrunk. Pisafe/Tools/Details will give you some info regarding the media (disk) partitioning.
You can turn off the sound in Settings. I wonder if I should default sound to OFF and allow users to turn it ON?

from pi-safe.

Hello Richard,

Last week I got a failure while booting a restored SDCard. I got a black screen not a rainbow.

It's very important to me to make working backups of my NAS. I have a RPI 3 running OMV and PI-Hole,

But today it worked like a charm.

I didn't notice there was an option for sound=on/off, thanks a lot.

The option "auto_expand_fs" has effect only while restoring SDCard, or creation too???

I made 2 backup tests, one reading from mmcblk0 and other reading from sdb (card reader):

Pisafe reading mmcblk0

~ Backup complete.
│ ' - 29G (/dev/mmcblk0)' backed up to
│ '/home/pi/Downloads/2022-04-17-mynasmmc.img.zip'
│ 28.9gb reduced to 1.07gb in 27 min 49 sec.
│ ▒
│

pi@raspberrypi:~ $ pisafe
PiSafe 1.2.5 i
PiSafe 1.2.5 i Backup...
No extension specified. Adding '.img.zip'
OUT-FILE='/home/pi/Downloads/2022-04-17-mynasmmc.img.zip'
28.9gb to read from '/dev/mmcblk0'
105gb available space on '/home/pi/Downloads'

~ PiSafe 1.2.5 i Backup '/dev/mmcblk0' to '/home/pi/Downloads/2022-04-17-mynasmmc.img.zip'
~ Step 1 of 3 - Copying '/dev/mmcblk0' to '/home/pi/Downloads/2022-04-17-mynasmmc.img' ...
dom 17 abr 2022 13:48:30 -03
Media size=28.9gb
Skipping 0 of freespace at end of media.
Reading 28.9gb...
~ Running: sudo pv /dev/mmcblk0 -p -s 31104958464 | sudo dd bs=4194304 of='/home/pi/Downloads/2022-04-17-mynasmmc.img' count=7417 iflag=fullblock conv=fsync
[========================================================================>] 100%
7416+0 registros de entrada
7416+0 registros de saída
31104958464 bytes (31 GB, 29 GiB) copiados, 1096,86 s, 28,4 MB/s
Done copying media '/dev/mmcblk0'
'29G /home/pi/Downloads/2022-04-17-mynasmmc.img'
Step 1 took 18 min 22 sec

~ Step 2 of 3 - Shrinking filesystem ...
~ Running: sudo pishrink.sh -s '/home/pi/Downloads/2022-04-17-mynasmmc.img'
pishrink.sh v0.1.2
pishrink.sh: Gathering data ...
Skipping autoexpanding process...
pishrink.sh: Checking filesystem ...
rootfs: 90416/1876800 files (0.1% non-contiguous), 993260/7527424 blocks
resize2fs 1.46.2 (28-Feb-2021)
pishrink.sh: Shrinking filesystem ...
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/loop0 to 1038630 (4k) blocks.
Begin pass 2 (max = 421717)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 230)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 9679)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop0 is now 1038630 (4k) blocks long.

pishrink.sh: Shrinking image ...
pishrink.sh: Shrunk /home/pi/Downloads/2022-04-17-mynasmmc.img from 29G to 4.3G ...
Done shrinking filesystem.
'4,3G /home/pi/Downloads/2022-04-17-mynasmmc.img'
Step 2 took 3 min 53 sec

~ Step 3 of 3 - Compressing '/home/pi/Downloads/2022-04-17-mynasmmc.img' to '/home/pi/Downloads/2022-04-17-mynasmmc.img.zip' ...
dom 17 abr 2022 14:10:45 -03
Compression set to level 5 of 9
4.21gb to compress.
Each dot=86m
/home/pi/Downloads/2022-04-17-mynasmmc.img [........................|.........................] 100%
~ Running: zip -dbds 86m -m -5 '/home/pi/Downloads/2022-04-17-mynasmmc.img.zip' '/home/pi/Downloads/2022-04-17-mynasmmc.img'
[ 0/4.2G] adding: home/pi/Downloads/2022-04-17-mynasmmc.img .................................................. (deflated 75%)
Done compressing '/home/pi/Downloads/2022-04-17-mynasmmc.img' to '/home/pi/Downloads/2022-04-17-mynasmmc.img.zip'
1,1G /home/pi/Downloads/2022-04-17-mynasmmc.img.zip
Step 3 took 5 min 34 sec
Press any key to return

Pisafe reading sdb

                                                                  │ 

│ ~ Backup complete.
│ 'Generic STORAGE_DEVICE - 29G (/dev/sdb)' backed up to
│ '/home/pi/Downloads/2022-04-17-mynassdb.img.zip'
│ 28.9gb reduced to 1.07gb in 22 min 1 sec.
│ ▒
│ ▒
│

pi@raspberrypi:~ $ pisafe
PiSafe 1.2.5 i
PiSafe 1.2.5 i Backup...
No extension specified. Adding '.img.zip'
OUT-FILE='/home/pi/Downloads/2022-04-17-mynassdb.img.zip'
28.9gb to read from '/dev/sdb'
104gb available space on '/home/pi/Downloads'

~ PiSafe 1.2.5 i Backup '/dev/sdb' to '/home/pi/Downloads/2022-04-17-mynassdb.img.zip'
~ Step 1 of 3 - Copying '/dev/sdb' to '/home/pi/Downloads/2022-04-17-mynassdb.img' ...
dom 17 abr 2022 14:28:34 -03
Media size=28.9gb
Skipping 0 of freespace at end of media.
Reading 28.9gb...
~ Running: sudo pv /dev/sdb -p -s 31104958464 | sudo dd bs=4194304 of='/home/pi/Downloads/2022-04-17-mynassdb.img' count=7417 iflag=fullblock conv=fsync
[========================================================================>] 100%
7416+0 registros de entrada
7416+0 registros de saída
31104958464 bytes (31 GB, 29 GiB) copiados, 744,816 s, 41,8 MB/s
Done copying media '/dev/sdb'
'29G /home/pi/Downloads/2022-04-17-mynassdb.img'
Step 1 took 12 min 30 sec

~ Step 2 of 3 - Shrinking filesystem ...
~ Running: sudo pishrink.sh -s '/home/pi/Downloads/2022-04-17-mynassdb.img'
pishrink.sh v0.1.2
pishrink.sh: Gathering data ...
Skipping autoexpanding process...
pishrink.sh: Checking filesystem ...
rootfs: 90416/1876800 files (0.1% non-contiguous), 993260/7527424 blocks
resize2fs 1.46.2 (28-Feb-2021)
pishrink.sh: Shrinking filesystem ...
resize2fs 1.46.2 (28-Feb-2021)
Resizing the filesystem on /dev/loop0 to 1038630 (4k) blocks.
Begin pass 2 (max = 421717)
Relocating blocks XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 230)
Scanning inode table XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 9679)
Updating inode references XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop0 is now 1038630 (4k) blocks long.

pishrink.sh: Shrinking image ...
pishrink.sh: Shrunk /home/pi/Downloads/2022-04-17-mynassdb.img from 29G to 4.3G ...
Done shrinking filesystem.
'4,3G /home/pi/Downloads/2022-04-17-mynassdb.img'
Step 2 took 3 min 41 sec

~ Step 3 of 3 - Compressing '/home/pi/Downloads/2022-04-17-mynassdb.img' to '/home/pi/Downloads/2022-04-17-mynassdb.img.zip' ...
dom 17 abr 2022 14:44:45 -03
Compression set to level 5 of 9
4.21gb to compress.
Each dot=86m
/home/pi/Downloads/2022-04-17-mynassdb.img [........................|.........................] 100%
~ Running: zip -dbds 86m -m -5 '/home/pi/Downloads/2022-04-17-mynassdb.img.zip' '/home/pi/Downloads/2022-04-17-mynassdb.img'
[ 0/4.2G] adding: home/pi/Downloads/2022-04-17-mynassdb.img .................................................. (deflated 75%)
Done compressing '/home/pi/Downloads/2022-04-17-mynassdb.img' to '/home/pi/Downloads/2022-04-17-mynassdb.img.zip'
1,1G /home/pi/Downloads/2022-04-17-mynassdb.img.zip
Step 3 took 5 min 50 sec
Press any key to return

And 2 restore, 1 to mmcblkp0 and other to SDB (faster).

Restore to sdb

                                                                  │ 

│ ~ Restore complete.
│ '/home/pi/Downloads/2022-04-17-mynasmmc.img.zip' written to
│ 'Generic STORAGE_DEVICE - 29,7G (/dev/sdb)'
│ in 5 min 10 sec.
│ ▒
│

Writing '/home/pi/Downloads/2022-04-17-mynasmmc.img.zip' to '/dev/sdb' ...
dom 17 abr 2022 15:03:50 -03
~ Erasing MBR, signature, and partition table from '/dev/sdb'...
~ Running: sudo dd if=/dev/zero of=/dev/sdb bs=512 count=2 > /dev/null
2+0 registros de entrada
2+0 registros de saída
1024 bytes (1,0 kB, 1,0 KiB) copiados, 0,00411544 s, 249 kB/s
~ Running: unzip -p '/home/pi/Downloads/2022-04-17-mynasmmc.img.zip' | pv -s 4526858752 | sudo dd of=/dev/sdb bs=4M conv=fsync

Press any key to return

Restore to mmcblk0

                                                                  │ 

│ ~ Restore complete.
│ '/home/pi/Downloads/2022-04-17-mynassdb.img.zip' written to
│ ' - 29,7G (/dev/mmcblk0)'
│ in 5 min 26 sec.
│ ▒
│ ▒
│

Writing '/home/pi/Downloads/2022-04-17-mynassdb.img.zip' to '/dev/mmcblk0' ...
dom 17 abr 2022 15:24:23 -03
~ Erasing MBR, signature, and partition table from '/dev/mmcblk0'...
~ Running: sudo dd if=/dev/zero of=/dev/mmcblk0 bs=512 count=2 > /dev/null
2+0 registros de entrada
2+0 registros de saída
1024 bytes (1,0 kB, 1,0 KiB) copiados, 0,0269231 s, 38,0 kB/s
~ Running: unzip -p '/home/pi/Downloads/2022-04-17-mynassdb.img.zip' | pv -s 4526858752 | sudo dd of=/dev/mmcblk0 bs=4M conv=fsync

Press any key to return

Thanks again.

See you later,

Cury

from pi-safe.

Hello Cury,

The logs you send look good to me (unless I missed something).

The design of PiSafe is to create your own small image file from a linux system. For example, you have just got your new Pi up and running on Bullseye, changed the language to Portuguese, installed and configured pi-hole. Now you want to preserve that work so if something goes wrong in the future, you can restore back to that point and not have to go back to the beginning. Shutdown the system, boot off a different sd-card, put your pi-hole sd-card in usb reader (probably sda), so it is not being written to. THEN use PiSafe to create an image backup of sda.

PiSafe creates the image file in three steps. The first step creates a byte-by-byte image-file-copy of the media device. This is the only step where we need to worry about disk activity. You want NO disk activity on the source media device during this step. Step 2 and 3 shrink and compress the image file and do not have anything to do with the source media device anymore.

By default PiSafe sets up "auto_expand_fs", which sets up a little code on the image to expand the file system upon first boot. This can be turned off. It is implemented during step 2 of 3.

Restore failures would most likely be caused by:

1. Writing to the source-media-device during step 1 of the backup
2. Restoring to defective media.
3. Defective pi. (not likely in my experience)

Peace, Richard

from pi-safe.