Backup in the cloud – no .tar backup file created

[andyzle]

Hello @framps, for my Raspberry Pi4 I try to backup in the cloud (MagentaCloud via webdav) using tar (rsync currently not supported, hardlinks cannot be created). RaspiBackup V0.6.8 finished with Returncode 0 and information that backup was successful. Backup files backup.img, backup.mbr, backup.sfdisk, raspiBackup.log and raspiBackup.msg were created but not the .tar backup file. I can see during backup process that temporary a file e.g. raspi4-tar-backup-20230109-183539.tar.part is generated in the backup destination folder but deleted at the end of the backup process (> 90 min. after message “RBK0167I: Eine eMail wird versendet.)”. raspiBackup is reporting a backup time of around 8 minutes which is much too less for 4GB data volume having 36Mbit/s max. upload performance. Three times tested – same results. Any ideas how to fix it?

[framps]

You're the first one - at least to my knowledge - who tries to use a webdav backup space. So you're a raspiBackup webdav guineapig :wink:

If you attach the debug log in this issue I can check what's going on there.

raspiBackup is reporting a backup time of around 8 minutes which is much too less for 4GB data volume having 36Mbit/s max. upload performance.

That's mostly related to the fact that webdav uses a local cache on your system and the whole backup is stored somewhere locally and raspiBackup finishes and then webdav starts to xfer the whole backup stuff to your remote site.

[andyzle]

You're the first one - at least to my knowledge - who tries to use a webdav backup space.

Possibly - nevertheless hope to get it working 😉

Debug log: raspiBackup.log

[framps]

20230109-184400 DBG 4396:                  *** ls -la /media/magentacloud/@HOSTNAME@/@HOSTNAME@-tar-backup-20230109-183539
20230109-190019 DBG 4396:                      total 4081946
20230109-190019 DBG 4396:                      drwxr-xr-x 2 root root        272 Jan  9 18:37 .
20230109-190019 DBG 4396:                      drwxr-xr-x 4 root root        192 Jan  9 18:37 ..
20230109-190019 DBG 4396:                      -rw-r--r-- 1 root root  268435456 Jan  9 18:36 @HOSTNAME@-backup.img
20230109-190019 DBG 4396:                      -rw-r--r-- 1 root root        512 Jan  9 18:36 @HOSTNAME@-backup.mbr
20230109-190019 DBG 4396:                      -rw-r--r-- 1 root root        181 Jan  9 18:36 @HOSTNAME@-backup.sfdisk
20230109-190019 DBG 4396:                      -rw-r--r-- 1 root root 3911475200 Jan  9 18:43 @HOSTNAME@-tar-backup-20230109-183539.tar

That's what I see in the debug log when raspiBackup finishes: All backup files are in the backup directory. Now it's the webdav service which has to xfer all this stuff to your remote location. From a raspiBackup perspective the backup was ok. If there are files missing on the backup site that seems to be an issue of webdav or some other components involved in the xfer process.

You wrote all files are xferred but not the tar file. Maybe there is some webdav size limit by your provider? All files are quite small but the tar file is huge.

As far as I know webdav caches all stuff locally first and then starts to xfer all data. I'm not very familiar with webdav. What I would do first now: Check the webdav logs. For me it sounds webdav is not able to xfer the huge file. The tar file has a size of 3.6 GB ...

[framps]

I just configured webdav access to my provider (1&1) via an AVM Fritzbox 7590 and started a backup.

I got

tar: /var/cache/davfs2/sd2dav.1und1.de+remote-webdav+root/troubadix.framp.de-tar-backup-20230111-210058.tar-A2r0S8: file changed as we read it

Now I use option -u "\--exclude=/var/cache" to exclude this useless stuff in the backup and will check whether the backup succeeds.

[framps]

Finally after 1h the backup finished successfully with my 10Mb upload connection. When I backup this system on my NAS it takes 16 Minutes.

/remote/webdav/troubadix/troubadix-tar-backup-20230111-215657 $ ls -lah
total 2.3G
drwxr-xr-x 2 root root  392 Jan 11 22:48 .
drwxr-xr-x 3 root root  136 Jan 11 21:57 ..
-rw-r--r-- 1 pi   pi    88K Jan 11 22:48 raspiBackup.log
-rw-r--r-- 1 pi   pi   1.9K Jan 11 22:48 raspiBackup.msg
-rw-r--r-- 1 root root 256M Jan 11 22:02 troubadix-backup.img
-rw-r--r-- 1 root root  512 Jan 11 21:59 troubadix-backup.mbr
-rw-r--r-- 1 root root  195 Jan 11 21:58 troubadix-backup.sfdisk
-rw-r--r-- 1 root root 2.0G Jan 11 22:20 troubadix-tar-backup-20230111-215657.tar

This proves it's possible to store the backup on webdav. If you have any issues with the webdav upload you have to check your local setup and configuration. It's not a raspiBackup issue - just a networking/webdav issue because raspiBackup only uses the existing network infrastructure which has to be OK.

[andyzle]

Thank you for checking my log, testing the webdav upload and related feedback.

Now I use option -u "--exclude=/var/cache" to exclude this useless stuff …

Yes, I got the same message in the past, in addition some “socket ignored” warnings. Therefore in parameter DEFAULT_EXCLUDE_LIST I added --exclude=/var/cache/davfs2/* --exclude=/var/lib/samba/private/msg.sock/* --exclude=/home/pi/.pcsc*

As far as I know webdav caches all stuff locally first and then starts to xfer all data.

As I can see webdav stored temporary in the (so far existing) file /var/cache/davfs2/magentacloud.de-remote.php-webdav+media-magentacloud+root/raspi4-tar-backup-20230109-183539.tar-VKoLEQ which was the reason for the “file changed as we read it” abort. That is on source side everything seems to run perfect.

What I would do first now: Check the webdav logs

I saw following message in the syslog every 10 seconds: mount.davfs: open files exceed max cache size by 3679 MiBytes I will investigate the root cause. I seem to have incorrect parameters in the davfs.conf.

[github-actions[bot]]

This issue is considered stale now and will be closed automatically in 1 week if there is no activity any more

[andyzle]

@framps As you have proved my problem with backup into the Cloud is not a raspiBackup issue. Root cause is Magenta cloud having ongoing problems with up-/download of big files, see Sammelthread: Magenta Cloud 1GB Up-/Download Problem via Browser/WebDAV. Now I would try with ionos/1&1/HiDrive cloud storage as backup target which worked for you. According to their website it supports rsync protocol. My question: Might it be possible to have raspiBackup and this cloud storage as backup target using rsync protocoll, even though you ruled out this (no hardlink, no ext3 or ext4 file system)?

[framps]

Now I would try with ionos/1&1/HiDrive cloud storage as backup target which worked for you.

Well, I didn't use 1&1/Hidrive. I used the normal webdav access to my 1&1 Cloud Storage I have because 1&1 is my internet provider. That's the mount I used.

https://sd2dav.1und1.de        /remote/webdav  davfs   rw,noauto,user  0       0

But according their website they support

SFTP/FTPS, WebDAV, SMB/CIFS, rsync, SCP and Git. 

and WebDav is included. You even can use SMB/CIFS if you want.

Might it be possible to have raspiBackup and this cloud storage as backup target using rsync

Unfortunately not :cry: This would be a very useful feature in raspiBackup. I spent a lot of time and tried to add rsync protocol support to raspiBackup (See this branch) but I didn't find a nice way to integrate rsync support into raspiBackup. raspiBackup was designed to have the backup partition mounted. The rsync protocol which supports hardlinks et al is a new protocol for raspiBackup and requires a lot of new code to be written. In addition ssh access is required in order to maintain the backup versions which makes the whole backup version handling even more complex.

raspiBackup is written in bash. In order to add the rsync protocol raspiBackup would have to be rewritten in a higher language like C++ or go. I thought about this - but it's too time consuming and given the fact there is a very small number of people who asked for rsync protocol support I don't spend this effort. Keep in mind: I wrote raspiBackup to backup my Raspberries and never had in mind to use remote storage.

If you want to use the rsync protocol you have to write your own code - unfortunately.

If you want to use raspiBackup you have to use the tar backup type.

[andyzle]

I used the normal webdav access to my 1&1 Cloud Storage

Ah, OK – I have access to 1&1/Hidrive offered to me from 1&1 which is my email / domain provider.

If you want to use raspiBackup you have to use the tar backup type.

I will test the tar backup type with Hidrive cloud storage. My fallback is my old NAS to be replaced by a new one if necessary (I hoped to replace by cloud storage totally). Regarding rsync protocol support I can fully understand not to spend endless time because this is not part of the raspiBackup core functions. However, thank you for your support.

[framps]

Thank you very much for your donation :+1:

[andyzle]

Update: after fighting down some unrelated problems I managed to backup and restore using ionos/HiDrive cloud storage and tar backup type, with unexpectedly fast cycle times.

[framps]

Thank you very much for your update. I'm glad you finally managed to use raspiBackup to backup and restore your Raspberries to HiDrive.

Would be nice if you share your gotchas when you configured HiDrive :wink:

[andyzle]

These are my experiences:

• use cloud storage for backup only with reliable cloud provider and fast connections, especially to have manageable backup upload times (my goal was: should be much less than 1h), test backup/restore process carefully.
• from my point of view Magenta cloud is currently not applicable for tar-based backup due to having ongoing problems with up-/download of big files, see above (rsync is not supported which might overcome the big file issue).
• my experience with ionos/HiDrive having 40/100 MBit/s internet up-/download speed: 4GB backup/restore in ~30 min. / ~20 min.
• As framp stated above, up-/download via davfs2 is a file buffered transfer (see e.g. folder/var/cache/davfs2/++/), therefore be aware that the backup/restore process might be not completed although raspiBackup reports its finished, especially true for the restore process – a look on your router’s online monitor tells the truth.
• if you have ongoing “mount.davfs: open files exceed max cache size by MiBytes” errors in the log, check e.g. this thread WEB-DAV Linux File System(davfs) Discussion where former davfs2 developer Werner Baumann explains the davfs2 cache.

[framps]

Great :+1: Thank you very much you shared your gotchas very detailed :+1:

[filetto]

I'm facing a similar behavior with webDAV:

20240209-150231 DBG 3687: --> supportsHardlinks /home/@USER@/nextcloud cp: cannot create hard link '//home/@USER@/nextcloud/raspiBackup.hlinklink' to '//home/@USER@/nextcloud/raspiBackup.hlinkfile': Function not implemented 20240209-150232 DBG 3700: --- Links: 1 cp: cannot create hard link '//home/@USER@/nextcloud/raspiBackup.hlinklink' to '//home/@USER@/nextcloud/raspiBackup.hlinkfile': Function not implemented 20240209-150232 DBG 3700: --- Links: 1 cp: cannot create hard link '//home/@USER@/nextcloud/raspiBackup.hlinklink' to '//home/@USER@/nextcloud/raspiBackup.hlinkfile': Function not implemented 20240209-150232 DBG 3700: --- Links: 1 cp: cannot create hard link '//home/@USER@/nextcloud/raspiBackup.hlinklink' to '//home/@USER@/nextcloud/raspiBackup.hlinkfile': Function not implemented 20240209-150232 DBG 3700: --- Links: 1 20240209-150232 DBG 3710: <-- supportsHardlinks 1

can't get it to work.. I did the webDAV setup following this tutorial: https://docs.nextcloud.com/server/latest/user_manual/en/files/access_webdav.html

I'm able to create files and folders through the webDAV connection. But raspiBackup is failing with the mentioned error. Anybudy has an Idea? Many thanks in advance!

[framps]

I'm facing a similar behavior with webDAV:

No. It's a different issue because you use the rsync backup type. rsync does not work with webdav.

Quote from first sentence in this issue:

using tar (rsync currently not supported, hardlinks cannot be created).

[filetto]

Thank you VERY much for this quick response! Seems to work now.