Selectively restoring data only for certain rows is super hard. But the communications by Atlassian has been the worst I have ever seen in the industry.
We use Jira, but it's self-hosted for my team. Maybe other teams that have transitioned to the cloud version are aware that there's a problem, but I haven't heard about it.
Granted that's how all lies start / what sometimes people assume and they're wrong but ... maybe this is that time?
Maybe it is in fact so bad that honesty would be a push or worse?
In my opinion, such a scenario does not exist. Transparency always in all things.
At least explain why there was such a total communication blackout company wide. Even support staff weren't allowed to discus it. Why?
What's the right way to structure your data here that would make restoring more straightforward here? Is this backup/restore scenario niche or they should have designed for it?
a) overwhelmed by creeping featuritis, each customer's data has relationships to global tables, and
b) they backup their entire database cluster in one snapshot
and there maybe other gotchas for restoration, like relying on denormalized views and caches that have to be rebuilt. they may also have erroneously assumed that data protection's main value driver is whole-of-system disaster recovery, which can lead to pathologies such as "we don't have a single-customer restoration tool".
this is not a niche scenario
What are the downsides to this?
* disaggregates data that the SaaS might be interested in querying/updating as an aggregate
* not all ORM frameworks handle this case well, if at all
* dumps are more than a single trivial command
basically all your data operations gain an additional dimension of complexity, and you may not perceive the benefits until much later
typically this is probably for internal reporting/metrics. But yeah, a custom script with direct SQL is in order. Personally my opinion is avoid ORM at all costs. Never seen a benefit that wasn't trivially done in SQL, and the downsides are incredibly painful.
The big downside of sharding out, per customer, is that's a lot of databases to migrate on upgrades. Or rollback if shit hits the fan.
The upside? You can have customers on different versions of your app if you really wanted to do such a thing.
In any case, proper tooling goes a long way to making it the difference between wonderfully manageable and torturous nightmare. Think idempotent backup scripts that are capable of failing at any time and resuming where they died, etc.