Ah but were there any error messages. That simply means the script ran successfully, not that it backed up successfully!
[edit]
BTW, click on the reply button under my message (not the big blue one) or quote the message else the person you reply to, doesn’t know you replied to them.
When doing import archive and export data I can ONLY do it manually via SSH. The web interface does not work (when clicking on the options, nothing happens)
I manually exported an archive from my existing PI install and then immediately manually re-imported and all was good. So, thats positive…
When I try to import any of my OLD backups, NONE work. From my previous Ubuntu install I had kep the previous 4 backups - none worked. As @borpin mentioned, its possible thats a backup has errors but I would argue its unlikely all 4 do so…
I find interesting that the names generated are different…
emoncms-backup-emonpi-2024-11-21.tar.gz << from existing emon PI install
emoncms-backup-emonserver-2024-11-07.tar.gz << from previous Ubuntu install.
Is it possible naming conventions are affecting my data imports?
I am reaching the limit of my ideas… Altough I have backups from previous install, my old data appears to be lost…
That part of the name is simply the server / host name.
Actually, if there is something wrong with the backup script, then I think it is highly likely
That is a service runner issue.
I suspect there is a problem with the backup in Ubuntu. We know there are permission issues with an Ubuntu install. I never use emoncms backup on my Ubuntu setup (just get PVE to do a LXC backup).
Do you still have the old system? You could try and fix the backup.
First rule of backups is to not assume they will work
Indeed depressing - I dont have my old system… I have since formatted that machine
And, yes, I DID assume backups were good…
I have learned my lesson!!
Could you share your LXC backup process? What are your export time intervals? when You import that data to a new system how do you setup the imputs so the new feeds linkup seamlessly?
Did the data files at least survive? You said it was the SQL bit that failed? I think you can reconnect to the data files (the Feed data) - not completely sure - @TrystanLea?
BTW, you can just highlight the bit you want to Quote and click on ‘Quote’ in the pop-up dialogue.
You will need to check the file to see if the line exists as I don’t think it will in a backup from a new system. You can’t assume the line to remove does exist!
I think this problem will occur if it is a backup from an older system into a new system.
It might be better to remove the line on creating the backup.
New MariaDB versions create dump files with this sandbox mode command. Older versions do not understand this command, and they will error on it. Import will not proceed in this case.
In my example I have tried to import a backup created with 10.5.26-MariaDB-0+deb11u2 (with sandbox feature) on Pi OS 11 (bullseye) after upgrade to Pi OS 12 (bookworm) with 10.11.3-MariaDB-1+rpi1 (unfortunately without sandbox feature). Using an original Pi OS image I have run the EmonCMS Installation Script (init.sh) instead of using the official emonSD-01Feb24 image. So I am not sure if this problem is relevant for many users.
Today, I have tested my system with the addidional “tail +2|emoncms.sql” line that did not work. So it was not that easy.
Finally, I found a working solution by adding four lines to the import script after line 122, also including the conditional query, if the line does exist:
if grep -q "enable the sandbox mode" ${import_location}/emoncms.sql ; then
echo "Warning: removing sandbox mode command from emoncms.sql to be compatible with older MariaDB versions"
sed -i 1,1d ${import_location}/emoncms.sql
fi
BTW, after successful import, the ${import_location} folder still contained one file and one folder: The empty folder “phpfiwa” and “settings.ini” were not automatically removed by the import script. Maybe this can be added to the # cleanup section after line 152.
