Best backup strategy including low bandwidth
-
I use rsync with ssh keys myself. Means set it up once, write a bash script and tie a cron job to it. Allows you to routinely backup and rsync will only move what is new/updated.
Take into account you will be hard pressed to keep the data flowing if you have only allowed for so many tens of megabytes.
Fox -
@mattfox Yeah I've done something similar as I have some scripts collecting logs from other devices and using rsync to send it off-site.
Are you doing incremental backups of the NoSQL DB?
Take into account you will be hard pressed to keep the data flowing if you have only allowed for so many tens of megabytes.
Yeah that's why I was thinking if i just take the configuration backup and H2 Database backup off-site (as well as the long term data we get from the PTCP Connection). And just do incremental NoSQL DB Backups to the PC that's on site. That way I've at least got the config backups.
Excluding point data, will the H2 Database and Configuration.json be enough to get a new device up and running with the old configuration?
-
@cmason said in Best backup strategy including low bandwidth:
Excluding point data, will the H2 Database and Configuration.json be enough to get a new device up and running with the old configuration?
If you've got the SQL database backed up (H2,mysql,etc..) you'll be grand as that hosts all config info, point info, system configs, the whole shebang.
So as long as that's not an issue I think you'll be jammy.
Fox
-
@mattfox
So as long as that's not an issue I think you'll be jammy.Cool, Thanks Fox!
-
Anytime, just be mindful of database changes between module upgrades. The last thing you want is a corrupt DB. Be sure to backup the mango directory minus the backups and logs every time you run an upgrade - especially if this is a remote setup.
-
@mattfox said in Best backup strategy including low bandwidth:
Anytime, just be mindful of database changes between module upgrades. The last thing you want is a corrupt DB. Be sure to backup the mango directory minus the backups and logs every time you run an upgrade - especially if this is a remote setup.
Right, so like the whole /opt/mango/ directory?
-
The mango directory itself, don't need opt, here's a tar bz2 call to compress into a mango zip file...
This is me assuming you're using Linux though...
Not sure if bash for windows has it.cd /opt tar --exclude="mango/backup" --exclude="mango/logs" -jcvf ./YYYYMMDD_hhmm_mango_3_x_x.tar.bz2 mango
Replace YYYYMMDD_hhmm_mango_3_x_x. with timestamp and mango version for easy identification...
You may likely need sudo for the tar call if it fails to create the file.Fox
-
The core database - What does this keep?
All configurations. Used to restore the unit to exactly what it was configured apart from time-series data.JSON Configuration - What does this keep?
All configurations but can be considered a shallow copy of the configurations, This backup is not sufficient to restore an instance as when you import this the table id's will not be the same.The Mango NoSQL Database - I assume this is point history data?
Correct, all-time series data is stored here. -
@craigweb said in Best backup strategy including low bandwidth:
The core database - What does this keep?
All configurations. Used to restore the unit to exactly what it was configured apart from time-series data.JSON Configuration - What does this keep?
All configurations but can be considered a shallow copy of the configurations, This backup is not sufficient to restore an instance as when you import this the table id's will not be the same.Thanks Craig.
I've got three identical deployments to go out. What's the best way to copy the configuration over if I develop on one HTS unit and then copy it to the other two?
-
If it's just configuration, use the json configuration export as a base template then amend your XIDs for each of the mango units and import that over the top.
Fox