search

TransparentWorld / Issues

TransparentWorld-Issues
MIT License
0 stars 0 forks source link

Automated Backups #65

Closed farley13 closed 7 years ago

farley13 commented 7 years ago

We should backup the production DB to S3 daily - it should be pretty small - and likely old copies won't need to be removed anytime soon.

akarasev commented 7 years ago

I'm thinking about implementation. What about a shell script into a VM instance with PostgresSQL container running? Shell script creates SQL dump and uploads it to S3 bucket using AWS CLI. To run it daily I'll create a cron task into the same VM instance.

farley13 commented 7 years ago

sounds good to me - we should have the test db restore from the backup once a day as well - will help making sure the backups are working correctly as well. Having both built into the db image makes sense to me.

akarasev commented 7 years ago

To be aware about backup/restore status, wouldn't be better to create Jenkins job?

farley13 commented 7 years ago

I'd be ok with either - as long we are alerted when it fails - jenkins would be easier to keep an eye on - as long as it doesn't break if we need to kill/redeploy a DB copy.

On Wed, Nov 9, 2016 at 9:58 PM, akarasev notifications@github.com wrote:

To be aware about backup/restore status, wouldn't be better to create Jenkins job?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/TransparentWorld/Issues/issues/65#issuecomment-259589696, or mute the thread https://github.com/notifications/unsubscribe-auth/ABYh1JHWnPhF3ftDVhpsCyxBLqlrc-ryks5q8ohwgaJpZM4KqK5o .

farley13 commented 7 years ago

This is now on Jenkins - closing out. Will open separate ticket for auto-redeploy of postgres/solr/prometheus