It seems sometimes now db-datanommer is taking more than 24hours to
backup, and currently that means it starts another one while the
previous one is running. Thats no good for anyone, so lets put in a lock
wrapper to avoid that.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
Currently backups are taking 17-18 hours with 4 threads.
Now that we have 16 cpus defined there, lets bump that up to 8 and see
if that lowers things much. If not we can look at moving to another
compression, but the database is very large so lots of compression is
good to save disk space.
Also filter out another output of the backup job that causes cron
emails.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
First we need to pipe stderr into the grep to filter out the timescaledb
warnings. So, |& does that.
Then, there's no reason to backup the staging database. Disable that.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
db-datanommer02 uses timescaledb. When you do a pg_dump there's warnings
due to this, but according to upstream they are all completely harmless.
So, to avoid an email to everyone every day, lets just try and supress
these, but yet hopefully not supress real errors if they every occur.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
