pauloserver
Member
- Joined:
- Jun 2024
- Posts:
- 117
- From:
- São Paulo, Brazil
I did this last month, going to tell you, going to be honest, you are very disorganized
But I help you. I check if your host has snapshot, it is more fast than restore from backup
My client he said "that new design is better" when I rollback his site, sometimes we are lucky
I make checklist after this, I sleep before 1am, I save you
chill infrastructure for chill people 🦫
ronwit
Member
Budget King
- Joined:
- Jun 2024
- Posts:
- 122
- From:
- Osaka, Japan
Oh no (´・ω・`) I basically did same thing actually last year
Staging db overwrite production, basically nightmare
Actually I have checklist now, I made after my accident. Basically you need:
- Separate database user for staging
- Different color terminal prompt for prod
- Pre-sync dry run script
Your client praised speed? Maybe rollback removed some heavy plugin kaomoji lucky
Did you check if staging had actually newer orders or basically empty? (´・ω・`)
instant noodles, instant deploys
ana_mad
Member
- Joined:
- Jun 2024
- Posts:
- 298
- From:
- Madrid, ES
Ouch, been there! I sent ticket yesterday to my host about this exact scenario—they see it constantly.
Here's my pre-deploy checklist, feel free to steal:
- SSH banner shows "PRODUCTION" in red
- Database name confirmation prompt
- Snapshot taken before any 2am "quick fix"
- Staging DB has _staging suffix always
Your client liked the speed? Classic! Sometimes accidental rollbacks remove bloat. But test your restore before celebrating—4 days of orders is real money.
@tomhider did staging have recent customer data or was it sanitized? Cheers
swimming upstream since 2019 🐟