Backup feedback over sshfs
-
@girish OK next time it breaks I'll send an email about it, leaving it as it is so that you can have a look, I already tried to find the reasons but beside "time-out" I couldn't find anything particular
checking everyday and now that I'm waiting for it to un-mount, it does not
haha -
@girish here we go :
This is after a reboot of the server.
but this time I clicked Remount Storage and instead of "removing" previous backups, everything is mounted and backups are listed as usual..
I think the other times this happened, I was going to Volumes, reconnect the mount (maybe this is what makes previous backups, inside the volume, unlisted after a remount?)
then go to backup and Remount the storage, but this time I just clicked once, in the backup view, remount storage and all is fine.
-
@rmdes thanks for the details. So this is the same issue with the systemd unit dependencies during boot. The mount units are simply skipped it seems due to this circular dependency. We have to fix this for the next release, just not yet sure how
-
@rmdes they are setup with systemd, so they are system-level already. The issue is DNS/unbound dependency for the mounting as well as docker for the volumes. Since there is some circular dependency currently, systemd breaks the circle by disabling the mount points during startup, which is causing the issue that they are not mounted after reboot.
-
@nebulon @girish Not in a hurry or anything, but the state bug is happening (happens at each reboot basically) I've left it unmounted and will for the weekend if at some point you want to SSH-support and retrieve log traces related to the mounting issue or I can post here if you indicate the commands you want to get more context ?
-
I have remounted the volume now and something that really is problematic with this type of backup is that, even when you remount the volume and storage backup location (that part works just great with two clicks) it seems previous backup at the mounted location are not listed, it's like a brand new freshly added volume/storage.
Meaning, previous backups can only be restored manually, they can be retrieved anymore from cloudron dashboard, the only way is to follow the manual instruction from the doc to retrieve backup ID etc..
manual remount wouldn't be an issue for my use case If I could get the existing backup listed when the volume/storage is remounted.
volume view remounted :
backup view remounted :
the backup listing view after everything is remounted :
I was wondering if it wouldn't be a good idea to have a button to rescan the backup target for backups that match previously made cloudron backups ?
-
I use a Hetzner storagebox via sshfs as backup provider and also have the issue with the volume being not mounted after reach reboot. Clicking the remount volume button solves it for me though. All previous backups are correctly listed after remounting.
Having to remount the volume manually is somewhat annoying though and I would appreciate a solution which solves the issue with the circular dependency on boot.
-
@rmdes actually I am not sure if you use that thing correctly. Volumes and the backup storage are not really related. The way you have it configured, the same mountpoint would be mounted twice. Once for the volume (which is supposed to be used within apps) and the backup storage.
@hendrikvl we try to fix this reboot and volume mounting issue in the upcoming release.
-
@nebulon wow, alright, I may have misunderstood the documentation then, will remove on the volume side
- now I remember, I had it on the volume because one of my apps/domains was reading a music folder from the same sshfs mount point, which happened to be the same storage.
-
@rmdes can you check on the server if
/mnt/cloudronbackupis actually mounted or not? seems to be some discrepancy here.Further, if you change the backup storage configuration, previous backups will be removed from the listing, since a new backup storage may have different mechanisms to access them and Cloudron only ever stores one storage configuration. Note that the backup meta info is stored in the database, so even if the files would be on that disk, Cloudron does not look around the disk and tries to find existing backups...maybe it should, but it doesn't currently.
-
@nebulon it is mounted, I can list all the backups just fine, it would be really neat to have cloudron reading some kind of index that could be generated after each backup keeping the backup directory tree index safe, even in between mounts ?
-
it's totally fine and normal that if backup type is changed that it looses the index, but here it's not the case, nothing was changed, the machine was rebooted and lost the backup mount, I manually remounted it, but all the previous backups are not listed, even tho it's the same backup config.
I created a new backup now and had to remove all the previous backups manually to make sure I have something I can use if I need to restore an app without crippling my backup storage with untied backups that I can only retrieve manually. -
A bonus I noticed by having my backup storage mounted a second time (not the case anymore) in the Volumes view is that I could via the file explorer manage my backups with the cloudron file explorer, pretty handy to delete unneeded parts or to manage a non backup folder for music etc..
-
-
@nebulon Maybe but I have no idea what can it be..
if I LS /mnt/cloudronbackup from the box everything is there
I will try to list /mnt/cloudronbackup next time the box reboot, before remounting in the UI and see what's up..- one question : does cloudron backup write an index somewhere inside the mounted backup ?
