MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.88k stars 497 forks source link

Can't get a succesful run of dietpi-backup #4301

Closed jpmurray closed 3 years ago

jpmurray commented 3 years ago

Required Information

Steps to reproduce

  1. Start the backup.
  2. Wait for it.

Expected behaviour

A complete backup of my system in the specified location

Actual behaviour

I'm getting a lot of rsync error "invalid arguments", but since there are files that are backing up, I guess this would be expected on some part of the process. But my main issue is that a couple of seconds in the backup, it just... Hangs. It never seems to be on the exact same file, but for some reasons that I can't figure out myself, dietpi-backup script runs for seconds then seemingly can't finish the rsync of a file and stays there until I ctrl+c my way out of it.

Extra details

Now I understand that this might be a topic for the forums, but I couldn't register (captcha is required, but won't show, even with every blocker I have disabled and cache purged πŸ€·β€β™‚οΈ), so I'm resorting to here.

Joulinar commented 3 years ago

Hi,

How long do you wait before canceling the backup? Usually it will take time to complete. It depends on size and speed of the disk. As well rsync will do differential backups. Means files changed in between will be copied only. Therefore you don't see same files again.

MichaIng commented 3 years ago

Jep, when it's looping through unchanged files, you'll not see any output for a while, but the "invalid arguments" errors should not be. Could you paste an example here?

captcha is required, but won't show, even with every blocker I have disabled and cache purge

EDIT: Can you please try it again? It seems the reCAPTCHA frame is now loaded from google.com instead of www.google.com, violating your CSP rules since two days.

jpmurray commented 3 years ago

@Joulinar I might not be waiting enough then. I'll try to keep my computer awake for a while, while it's running. I'll be reporting later on on the result ! But for now, I'm stuck at those in the console:

rsync: chown "/mnt/backups_on_nas/volume1/Backups/lib/modules/5.10.17-v8+/kernel/fs" failed: Invalid argument (22)
    206,475,631  81%   12.39MB/s    0:00:15 (xfr#2934, ir-chk=1092/5280)

@MichaIng : Yep, I could succesfully register now, thanks ! As for the rest, here's a couple of line, randomly choosen from the lot, from the latest run I did:

rsync: chown "/mnt/backups_on_nas/data/lib/modules/5.10.17-v8+/kernel/drivers/usb/usbip" failed: Invalid argument (22)
rsync: chown "/mnt/backups_on_nas/data/lib/modules/5.10.17-v8+/kernel/drivers/vhost" failed: Invalid argument (22)
rsync: chown "/mnt/backups_on_nas/data/lib/modules/5.10.17-v8+/kernel/drivers/video" failed: Invalid argument (22)
rsync: chown "/mnt/backups_on_nas/data/lib/modules/5.10.17-v8+/kernel/drivers/video/backlight" failed: Invalid argument (22)
Joulinar commented 3 years ago

You doing the backup to a NAS? Do you use NFS? What NAS you are using? A Synology?

jpmurray commented 3 years ago

@Joulinar all right, so I forgot it was running, then realized a couple of minutes ago that some of my services wheren't responding anymore. I had to kill the process and reboot. It was still at the same place it was on my last message.

I am indeed trying to back up to a mounted NFS share into a Synology DS214 Play.

Joulinar commented 3 years ago

You would need to set some specific thinks on the Synology if you like to save stuf via NFS on it. Just have a look to following forum post https://dietpi.com/phpbb/viewtopic.php?p=31342#p31342

MichaIng commented 3 years ago

Ah yes that explains it. I wonder why we do not check for UNIX permissions support explicitly, at least in case of NFS mounts. The function is there: https://github.com/MichaIng/DietPi/blob/dev/dietpi/func/dietpi-globals#L1213

@jpmurray Before you do the change suggested by Joulinar, could you try:

G_CHECK_FS_PERMISSION_SUPPORT /mnt/backups_on_nas/data && echo success

then redo the same after the change has been applied? Just to verify in your particular case.

jpmurray commented 3 years ago

All right, so I ran G_CHECK_FS_PERMISSION_SUPPORT /mnt/backups_on_nas/volume1/Backups/home-dietpi/ && echo success and it echo'd success without anything more.

Went to apply the change in DSM. Hostname part was just a wildcard, so I decided to go the network segment way allowing 192.168.86.0/24. Then the check permission function returned an error: Error creating directory /mnt/backups_on_nas/volume1/Backups/home-dietpi/, unable to check filesystem permissions Output on the console outside of the blue interface is mkdir: cannot create directory β€˜/mnt/backups_on_nas/volume1/Backups’: Read-only file system, although privilege is at read/write in DSM.

But now that this function tells me it can't create folder, I guess I might have been better with the wildcard? Entering directly the IP of the dietpi board gives me the same error for the check in filesystem permissions.

(At the point, I wonder if I should not just switch to another network share protocol...)

jpmurray commented 3 years ago

I'm going on a limb here, but might it not be a NFS permission issue ?

I scrapped all of DietPi's saved network share. Recreated the share on the NAS. Just to be sure I was all new.

I mounted the NFS. It not ask for any credentials, so I'm figuring it's connecting as guest, and I went on and gave guest read/write, again, just to be sure.

If I manually navigate to /mnt/nfs_nas/volume1/Backups/ I can create folders and files. Decided to then run again dietpi-backup, it ran, but I saw the same error as mentionned before and it stalled again on some file at arund 80% file transfer. If I check on the nas, I have a bunch of folders and file, which tells me dietpi-backup is indeed able to work with the NFS share.

Am I wrong thinking we're maybe looking it all from the wrong angle?

EDIT: a second run at dietpi-backup underlined the fact that the stalling always occurs at the same spot, beucase on each run, the backup folder on the NAS is at 222.8 MB. Never more, never less...

Joulinar commented 3 years ago

Writing the files to your Synology is not an issue. It's more the chown (change owner) command that seems not working. Means a test would be to create a demo folder and change owner to another user.

jpmurray commented 3 years ago

AH! Definitely! Folders and files under synology shows as "root".

Couldn't chown a test file to the user I have on my Synology because it doesn't exists in Dietpi. So I usedadd'd one, then tried chown again: chown: changing ownership of 'someuser': Invalid argument.

Joulinar commented 3 years ago

Change owner would need to be executed on DietPi system on the mounted NFS share. Will do a test later the evening once kids are sleeping.

Joulinar commented 3 years ago

ok I setup a NFS share on my Synology and was able to backup my system on it. Beside the fact that it was very slow, it was working well.

 DietPi-Backup
─────────────────────────────────────────────────────
 Mode: Backup

[  OK  ] DietPi-Backup | mkdir -p /mnt/nfs_client/dietpi-backup
[  OK  ] DietPi-Backup | rmdir /mnt/nfs_client/dietpi-backup
[  OK  ] DietPi-Backup | mkdir -p /mnt/nfs_client/dietpi-backup/data
[ SUB1 ] DietPi-Services > stop
[  OK  ] DietPi-Services | stop : cron
[  OK  ] DietPi-Backup | Free space check: path=/mnt/nfs_client/dietpi-backup/data | available=2036230 MiB | required=3234 MiB
[ INFO ] DietPi-Backup | Backup to /mnt/nfs_client/dietpi-backup in progress, please wait...
sending incremental file list
    627,665,859  98%  841.12kB/s    0:12:08 (xfr#18060, to-chk=0/23386)

sent 629,132,512 bytes  received 375,712 bytes  857,056.81 bytes/sec
total size is 638,653,683  speedup is 1.01
[ SUB1 ] DietPi-Services > start
[  OK  ] DietPi-Services | start : cron
[  OK  ] DietPi-Backup: Backup | Completed

I did not allow any special user on my Synology, just set the needed NFS permissions image


The only thing I adjusted, was the NFS mountpoint on DietPi /etc/fstab. I directly mounted the volume1 share like this

#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------
192.168.0.10:/volume1/NFS /mnt/nfs_client nfs nofail,noauto,x-systemd.automount
jpmurray commented 3 years ago

The only difference I had is that I was allowing connections from non-privileged ports, unchecked it, but it's not that, of course. I did adjust the mount point, it's easier for paths, but it's sadly not helping.

Can you confirm that you've enable the guest account for this in DSM ? Because I couldn't find a way to log a specific users mounting the drive in the interface.

Also, is it possible to enable a more verbose loggin on this? The fact that I'm stalling everytime on 34,346,168 86% 11.54MB/s 0:00:19 (xfr#3395, ir-chk=1010/5750) at the very same chunk tells me something is wrong with my files, no? My card isn't a cheap one, but what if ? I'd love to see what happens at first too, before the 2021/04/28 07:23:17 [5792] building file list which is the first line available in the logs...At the speed the chown errors are coming on screen, I just can't get a screenshot fast enough to get that part !

EDIT: I will find myself a USB key to try and backup to soon. I know it's not that, at least it doesn't seems like so, but I want to rule out every possibilities.

Joulinar commented 3 years ago

you simple can test the change owner issue by created a temp file on the nfs share as user root and afterwards try to change owner to user dietpi. This all to be done on the DietPi system.

On the Synology, no special user needs to be allowed

image

The NFS permissions are independent from this and needs to be set on the NFS Permission tab. There is no special user used to connect to the NFS server.

For testing purposes, you can create a backup on the SD card itself. Just change backup location to /mnt/dietpi-backup

By default you can't increase the verbose loggin, but at the end it's a simply rsync and you could try running it yourself setting the required debug level. However a log file is written to /var/log/dietpi-backup.log. It migt be empty as it get cleared on hourly basis.

jpmurray commented 3 years ago

And I finally got it working ! In DSM control panel, NFS settings had "Enabled NFSv4 support" checked. Unchecking it makes everything work perfectly smooth !

I'm going to close this now. Now, I'm on trying to automate the backups daily !

Joulinar commented 3 years ago

How is the performance if you backup to NFS, for me it was extremely slow during my test.

jpmurray commented 3 years ago

@Joulinar Read / write tests gave me around 72 mb/s. But the backup itself averages 7.5/8 mb/s.

Joulinar commented 3 years ago

Strange I didn't get more than 841.12kB/s

jpmurray commented 3 years ago

I don't know for you, but my board is wired, this might be it ?

Joulinar commented 3 years ago

No it's starting with quite good performance but it's dropping over time. Hm strange

jpmurray commented 3 years ago

Bar that, I'm getting a consistent 45 kb/s now, witth a rerun of the script to automate found on the forum ! But since it's incremental, so far, it still executes in a decent time.