Emoncms Backup Methods

Emoncms
1

Hi Glyn

Thanks. I am using the emonSD-03May16- RELEASE image which is running read-only so it looks as if I am good to go.

I will not bother with the hard drive.

Paul Reed updated his dropbox archive software so it runs on an emonpi taking care of the need to switch to read write and back again. I asked him if his tar.gz file was compatible with your backup tar.gz file because it it was re-instating a running system in the event of an SD failure would be very easy and quick. He was not sure but advised his format is:-

A single .tar.gz archive such as archive_11_08_2016_1425.tar.gz
and when decompressed, contains;

├── mysql
│ └── emoncms-11_08_2016_1425.sql
├── nodered
│ └── .node-red (entire directory)
├── phpfina
│ ├── 13.dat
│ ├── 13.meta
│ ├── 14.dat
│ ├── 14.meta
├── phpfiwa
├── phptimeseries
│ ├── feed_16.MYD
│ ├── feed_18.MYD
└── phptimestore

If the 2 backup methods produced a file suitable for import into emoncms it would possibly be helpful to a number of users.

Thanks for tweeting re nanodes. Following up direct.

1 Like
2

Yes pause script is great have not tested myself yet though.

I think the differences between two backup methods are significant it’s worth keeping the backup files separate to avoid user confusion. Instead of trying to work on a single common backup format we should probably work on a single backup method combining the best of @Paul script with the current emoncms backup module.

3

What is the structure of an emonpi backup, is the archive structure significantly different?
A ‘tree’ output ‘copy & paste’ would be useful, similar to the one posted above.
If just a tweak is needed to either/both backup systems, it may allow users to download the archive from dropbox to a usb stick and use the existing emonpi restore process.

Paul

4

current backup tar.gz structure is:

emoncms-backup-YYYY-MM-DD.tar.gz

emoncms.conf
emoncms.sql
emonhub.conf
phpfina/
phptimeseries/

Yes, it would be great if they were compatible. Just worried that it might cause confusion. I think in the future maybe your script could become the offical emoncms module the way it seems to be developing :slight_smile:

5

So I’m missing a backup of emoncms.conf and emonhub.conf, and the mysql backup needs to be in the archive root rather than mysql/

…and you’re missing the node-red backup.
If you decide to add the node-red backup, it’s safe to do a hot copy/restore of the .node-red directory, as it’s only read once when node-red first initializes, and also whenever a flow/node change is user deployed, otherwise it’s copied & run in RAM.

A few changes to both, and perhaps it could move integration a little closer.

In what way @glyn.hudson? Is there anything we could do to minimise.

Paul

6

Do neither of these back up emoncms/settings.php ?

Even if not used on a restore, it does give a source of reference to previous settings and an accessible record of the user/passwword details for mySQL and MQTT.

1 Like
7

It would be so much easier if all of the settings, configs, and data files were contained within a single directory, similar to the way node-red is structured.
Easy to back up and easy to restore.

Paul

1 Like
8

Good idea, I’ve just added backup up of settings.php to the emoncms/backup module

settings.php in included in the root of the backup tar.gz, it’s not imported via the import script.