MB/RPi - not enough space to restore database - but plenty of space available **solved**

[Gyvate]

the attached screencopies speak for themselves
nothing works
how to get my atabase restored ??
The message is pure nonsense (or just a secondary wrong message) as there is plenty of space available as the df -h shows
plus the database wasn't deleted as reported
the df -h was executed after the MB message showed in the log

is it that MB cannot handle the restore of large databases ?

[admin]

As you can see you added an additional mount point /tmp/mnt/data/HDD for your connected drive. Unfortunately, that causes problems with the database restore script, which inspects mount points and gets confused to see something unexpected.

In just released update I made the restore script more robust to that. However, please unwind all you special tweaks when you face an error to rule out that it is a modification you did that is causing the issue. Please be reminded that I only support stock Meteobridge installations, when you modify you are on your own. Thanks!

[Gyvate]

it works again - and now that I know why, even without that update - which is of course helpful and I'm sure that earlier or later some more users will benefit from it.

How was I supposed to know that the restore script (which is not directly accessible like the backup script) has issues with the backup device being already mounted to another mountpoint ?
The backup script doesn't have this issue. It mounts the external device to /tmp/backup even which the device is already mounted to another mountpoint.

Now, being named here as tweaker and reckless modificator for something very simple and logical, I should explain why I had this second mount point (which would normally disppear and unmounted at the end of the backup unless the mount directory was still open in the Windows Explorer).

When the database size grows over 4 GB, it can no longer be stored on an external USB device which is formatted with FAT32. Such a device (stick, thumb drive, disk drive) can easily be pulled of the MB USB port and plugged into a Windows computer to process the backup files (from simple checking, reading to copying etc.). Otherwise they are invisible to the user.

When the database size grows beyond 4 GB, you have to format the device with a different file system - Windows offers NTFS or exFAT, neither of them can be read by openWRT => Meteobridge (MB) won't write the backup. Therefore I chose ext4 which accepts files > 4 GB and can be recognized by openWRT (the underlying OS of MB). But you can no longer simply plug it into a Windows computer - Windows won't recognize the file system.

=> create a subdirectory in the exported SMB share (METEOBRIDGE\data) and mount the USB device into it e.g. into METEOBRIDGE\data\USB or METEOBRIDGE\data\HDD, whatever you name it. Then the content of the backup device can be seen and processed (!) in the Windows Explorer.

That's the modification I did. And every now and then the USB device is mounted into the exported SMB-Share as I want to see my backup files and also want to save the whole exported file system (templates, scripts, charts etc.) onto that drive - and save the backups to my NAS.

I think there will be earlier or later users here, who will also run into this 4 GB "trap" and who will still want to see these files (and maybe copy them somewhere else). They will then be happy that this can now be done.

[admin]

I didn't plan to insult you by calling your changes a tweak. In my view you did changes without fully understanding the impact on other operations and in my non-native understanding of English "tweak" seems to express this. However, sorry when you feel being called out by that, that was not intended.

it works again - and now that I know why, even without that update - which is of course helpful and I'm sure that earlier or later some more users will benefit from it.

I patched on your machine. All others will need to run the newest version, although nobody else did add additional mount points afaik.

How was I supposed to know that the restore script (which is not directly accessible like the backup script) has issues with the backup device being already mounted to another mountpoint ?
The backup script doesn't have this issue. It mounts the external device to /tmp/backup even which the device is already mounted to another mountpoint.

You will never know the side effects of changes you do to the system. How could you? You didn't program it. Some might be obvious, some unexpected. Better don't do or at least roll-back when problems occur. That is all I wrote.