It's not clear to me that this is really sufficient, or even really answers the original question.
On the sufficient side, I don't know that retaining an encrypted version of customer data would really meet a lot of compliance definitions for deleted data. Atleast, nothing I've heard of tested in court. Also, depending on the data, even tokenized / encrypted / etc approaches are easy to get wrong and still allow some correlation. In a previous company when it came to network tooling, we had to be extremely careful that we didn't intercept 1 bit of payload, as even though that 1 bit couldn't be used to meaningfully reproduce a phone call, by many legal definitions we would be illegally intercepting phone calls.
And then circling back to the original question, the problem of how to manage data and customer deletions if just shifted to how to do this with the tokens.
So my take on the original question is as follows. To my knowledge, the right to be forgotten compliance regimes do include time windows for deletions, understanding that it can take time to purge requested data. Also, some customers may want this in their contracts, so I'd try and align any contracts / terms of service with the most strict compliance regimes.
When taking backups, if possible use WORM (on S3 I think this is called object locks), and set the lock to be less time than the compliance regime requires, but long enough that there is always locked backups that can't be deleted by a mistake or adversary. Depending on required history, you can then just let the backups expire. If you need longer backup history than the compliance regimes allow, then it comes to structuring backups so selective data can be removed, and then relocking the backup. And doing this on a rolling basis, so at no point in time or run of the cleanup are all backups being touched at the same time.