Dietpi-Backup

[GnobarEl]

Hello all,

I'm trying for the first time the backup utility and I have some doubts.

My setup is the following:
1x RPi2
1x MicroSD 16GB
1x HDD 1TB
1x PenDrive 16GB

Theorically, I could be able to backup the RPi on the pendrive, but I'm not sure about this:



Anyone can explain me what is goinon? Its making the backup for arround 3 hours

Thanks.

[MichaIng]

@GnobarEl
Thanks for your report.

Please cancel the backup via <ctrl>+<c>, if not already done or it ran into full disk issue itself.

You should have received a prompt/warning, that you space seems to be insufficient, which allows you to exit or ignore.
However you should always have a careful look, if this warning appears. According to your screen it mentions a required disk space of 17968821 MiB = 1755 GiB = 1,71 TiB, so more than even your data HDD has.

Of course this does not make much sense on the system. I ran once into a similar issue, having a several Exabyte backup. It was due to SDcard corruption: There was one single file, having this enormous size and attempting to remove or handle it, lead to an I/O error.

Please check:
- /var/tmp/dietpi/logs/dietpi-backup.log to see on which file it hang. Hope it is actually logged.
- dmesg for emmc I/O errors.
- > /forcefsck to force a system partition file system check on next reboot.

[GnobarEl]

Hello!

First of all, thanks for your reply.

In fact, all you said is correct. I saw the warning, but, well, I decided to try, just to see how it goes. However I wasn't expecting that result

Do you think the issue here can be related with the HDD? I tried your advice but the result is the same.

Later on I will unplug the HDD and run the backup again...

Once again, thanks for your support!

Cheers.

[MichaIng]

The issue most likely is related to the SDcard. Those are known to break very fast and being vulnerable to corruption, especially used as system drive, due to the many small disk changes from the OS and installed packages.

Could you find the exact file, where the backup hang, by checking it's log?
Ah sorry, I was mistake about the log location, it's /var/log/dietpi-backup.log. Since this is in RAM and cleared every hour. So I guess you need to rerun the backup for a minute or such, cancel it again and then check the log:
tail /var/log/dietpi-backup.log

[GnobarEl]

Hello,

I tried your advice, but the log doesn't contain anything special. At least for me :p

Code: Select all

root@SquareServer:~# tail /var/log/dietpi-backup.log
DietPi-Backup Log File. 23-01-2019_2345


2019/01/23 23:46:29 [8680] building file list
2019/01/23 23:46:29 [8680] >f..t...... DietPi/dietpi/.network
2019/01/23 23:46:29 [8680] >f..t...... etc/fstab
2019/01/23 23:46:30 [8680] .d..t...... lib/modules/4.14.79+/kernel/drivers/char/broadcom/
2019/01/24 00:10:07 [8680] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(644) [sender=3.1.2]
root@SquareServer:~#

Any advice?

Thanks!

[GnobarEl]

@MichaIng
you are 200% correct!

After I looked inside the

lib/modules/4.14.79+/kernel/drivers/char/broadcom/

I noticed a huge file there



I deleted and I run the backup again.

I think it still have more corrupted files:

Code: Select all

rsync: readlink_stat("/usr/share/nmap") failed: Structure needs cleaning (117)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]
[FAILED] DietPi-Backup | Free space check: path=/mnt/penBACKUP/dietpi-backup/data | available=14151 MB | required=3944061 MB
[ INFO ] DietPi-Backup | Backup /mnt/penBACKUP/dietpi-backup: in progress, please wait...
sending incremental file list
    143,754,657   0%   19.59MB/s   15:13:36  xfr#1, ir-chk=2911/12317)

Lets see if I can fine more corrupted files.

Thanks for your support.

[GnobarEl]

Look like the backup is done!

Now, I just need to move the files from the PENdrive (where the backup is stored) and move to other SD card? Just copy paste?

Thanks for all your support.

Cheers.

[MichaIng]

Copy & paste works, but take care that file permissions are preserved, otherwise when restoring the backup without permissions, the system will not work properly. The target file systems needs to support them and e.g. use cp -a /source/dir /target/dir to have permissions preserved on copy.

Generally about file system corruption:
- Sometimes fsck needs to be done more than once to resolve all issues and also on reboot (non-interactively) not all cases will be cleaned, especially if this means that broken files are removed/lost.
- You will have best results, if you plug the SDcard into another external Linux system and run fsck interactively there.

[GnobarEl]

Thank you so much for your support.

This is what makes this the best image!

Once again, thanks.

Cheers!