Need to change backup location for export .tar.gz

I’m sure there is a simple solution to this but I’m not much of a programmer.
I want to backup my emoncms to a flash drive (/media/usb0) and not to the system SD card.

I have made the following change to /opt/emoncms/modules/backup/config.cfg:

# Destination location of exported backup .tar.gz - Must be writable

This works correctly but then the config.cfg is overwritten by the default version after the next update.
Obviously, I have something else to change but I’m at a loss what it is.

Thanks in advance to anyone pointing out my problem.

I don’t think the problem is one of your making. I’m running a test version of the new front end sketch in my emonPi, and if I stop and start that, or it restarts itself for any reason, emoncms automatically goes away and “downdates” itself, that sketch is wiped out and the default one re-installed. I’ve got a script to write it back, but it still needs human intervention. I think not enough consideration was given to the possibility that a user might want to not have the “standard” setup.

I’m not aware of a method of preventing that from happening. In my case, I don’t have an “unlimited” Internet tariff during the daytime, so I want to run costly updates between midnight and 8 am when I do have free data. In my book, automatic updates should be an option, not forced. It was forced updates that caused me to dump Mickeysoft and Windoze.

IIRC, there is a way to keep “changes” via the git stash command.


After stashing your changes via git stash

check out the branch you want your changes on, and then git stash apply. Then use git diff to see the result.

After you’re all done with your changes—the apply looks good and you’re sure you don’t need the stash any more—then use git stash drop to get rid of it.

I always suggest using git stash apply rather than git stash pop. The difference is that apply leaves the stash around for easy re-try of the apply, or for looking at, etc. If pop is able to extract the stash, it will immediately also drop it, and if you the suddenly realize that you wanted to extract it somewhere else (in a different branch), or with --index, or some such, that’s not so easy. If you apply, you get to choose when to drop.

A check should be made to not overwrite. A function of using an install script to do the updates :frowning:

I’ve created an issue Check if a config file already exists · Issue #65 · emoncms/backup · GitHub


1 Like

It doesn’t help in this case as the file config.cfg is not part of the Git repo and the file is in the .gitignore (quite rightly).

The problem is the script does not check to see if the file exists before creating a new one.

If the file is in the git repo, the script does not update from the repo (again, quite rightly).

However, the script does continue and will run the again for the module which should not happen.


Lots of ifs without elses as well (pet hate).

Thanks for the replies. I see what is happening and agree that the overwrite of config.cfg should be optional. I’m not familiar with the intricacies of git and will not attempt that approach.
Although I’m not a fan of using a penny in the fuse box, is there a simple workaround that I could use to avoid the changes in config.cfg such as removing part of this section of

# Creating backup module config.cfg file
echo "- Copying default.config.cfg to config.cfg"
cp default.config.cfg config.cfg
echo "- Setting config.cfg settings"
sed -i "s~USER~$user~" config.cfg
sed -i "s~BACKUP_SCRIPT_LOCATION~$backup_module_dir~" config.cfg
sed -i "s~EMONCMS_LOCATION~$emoncms_www~" config.cfg
sed -i "s~BACKUP_LOCATION~$emoncms_datadir/backup~" config.cfg
sed -i "s~DATABASE_PATH~$emoncms_datadir~" config.cfg
sed -i "s~EMONHUB_CONFIG_PATH~/etc/emonhub~" config.cfg
sed -i "s~EMONHUB_SPECIMEN_CONFIG~$emonhub_directory/conf~" config.cfg
sed -i "s~BACKUP_SOURCE_PATH~$emoncms_datadir/backup/uploads~" config.cfg

Thanks for the help.

For now I’d create a local copy of the settings and copy it back after any update. It is a simple fix (my bash is not good enough to do the PR) but hopefully @TrystanLea will pick this up.

Here’s my bash script to copy the front end sketch from my laptop into the emonPi, and subsequently upload it into the ATMega 328P. You won’t need the second part. Note I’ve got a pair of keyfiles set up as per the comment at the top. These authorise the machine the script runs on to access the Pi. Obviously you’ll need to change the machine, source and target to suit:


# Generate a SSH key pair with "ssh-keygen" Don't set a password.
# Keys are in /home/r/.ssh  files are private key: id_rsa; public key:
# Copy to the Pi with "ssh-copy-id [remote id]  e.g.remote-id = '[email protected]', password "emonpi2016" is required ]
# Needs SSH & SCP on source machine. Avrdude should exist on the Pi.

remotemachine='[email protected]'

echo This can take about 45 seconds to complete
echo Remote machine is $remotemachine

scp $sourcefile $remotemachine:$targetfile

ssh $remotemachine sudo service emonhub stop

ssh $remotemachine avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:$targetfile

ssh $remotemachine sudo service emonhub start


@bgrattan A fix has been released by @TrystanLea - smart work.

If you update now, it should leave the config file alone.

Robert, you have grabbed the wrong end of the stick. This was a problem with the EmonCMS Backup module - nothing to do with any sketch.

So have you - yet again. Have you read what the script does - and what I wrote wasn’t needed?

I can’t tell the difference - apart from file names and paths - between copying one sort of file and copying a different sort of file. It’s the same problem, transferring the file from a computer being driven from a keyboard (and not even that, necessarily, it could be a cron job) to the emonPi.

Not needed as fixed at source - sledgehammer to crack a nut.

I must still be doing something wrong here.

  1. I modified config.cfg and set the backup location to /media/usb0.
  2. Ran backup from console and everything worked correctly with .tar.gz
    file sent to the correct location.
  3. Ran full update from console.
  4. Checked config.cfg and found it had been replaced as before with default.config.cfg.

Is full update not the correct way to go? Do I need to modify config.cfg each time I do a full update?
Sorry to be a bit dense on understanding here. Thanks.


It looks like you might usefully use my sledgehammer technique after all. Here’s a shortened version that will, when everything is set up, copy the file sourcefile on your laptop or whatever to the Pi remotemachine at the location with the name targetfile. Obviously, you need to change those to suit.

I’ve updated the backup module to include the fix to stop config.cfg being overwritten: only creates config.cfg if it does not exist · emoncms/[email protected] · GitHub (Released to stable v2.2.8)

Thanks and much appreciated TrystanLea!