Hello everyone. Is there a best practice or some workflow for doing rollbacks in AWS/Spryker Cloud environment? Rolling back the code base to a previous version is just a matter of creating containers from some older images, but what is the right (or the best) way to roll back database, redis and elasticsearch?

Hi Neven. Great question. Let me that that to our experts. I will keep you posted

Hi @polite-intern-55963, it is not so urgent. I would be happy if i get an answer until the end of next week.

should be doable, i will keep you posted

thanks 👍

Still in the works, sorry

any update? This is a very interesting question

Let me check the status on it

thx, this is just a documentation how to restore a database backup. I'm more interested in rolling back a deployment without deleting data. When restoring the backup, things like e.g. orders or new customer accounts that happened in the meantime will be deleted

Hi Philipp, There are 2 different options, what is possible to rollback, actually 3 when needed: 1. DB: using a previously created snapshot you can restore the whole DB (structure + data) 2. Application: using a deploy function with a dedicated version (GitHub commit) 3. Do steps 1 and 2 simultaneously It sounds to me you are asking about the 2nd step and it is covered in the documentation here: https://cloud.spryker.com/docs/deploying-in-a-production-environment#roll-back-an-application Could you please check it and let us know if that is what you are looking for? Thank you. P.S. there is no backup and this restore solutions for redis, ES at the moment.

So basically suggested way to go is to • deploy older docker image • restore a db from a snapshot and then run data sync to sync the data with ES and redis Is there a reason why aren’t you suggesting the Propel Migrations? This seems to me a better way to revert the database structure without loosing the data. If we restore the DB from a snapshot, it would mean that we lose potential data saved since last snapshot (max 1 hour in this case), which, in a high traffic shop, would mean a large potential loss.

Propel Migrations are also possible, but requires code changes. With RDS backup/restore no code changes are needed, as only AWS services need to be triggered. It is just a different approach.

RDS Backup & Restore is of cause the "easier" way, but as Neven wrote, there will be a loss of data, which doesn't sound too cool