That would work if you kept only backup version. That would be bad-what do you do in case of accidental record deletion or encryption malware detected after a backup? Check out e.g. https://www.backblaze.com/blog/the-3-2-1-backup-strategy/

For new systems where this sort of privacy requirement can be designed in from the start, I quite like a strategy that was proposed around the time of the big GDPR discussions, which seems useful in some situations: individually encrypt records of personal data with a separate key for each person (or some other granularity that makes sense for your processing and storage requirements). Then your main database and its backups only contain the separately encrypted data, you keep a rolling backup of your current set of encryption keys, and in response to any permanent data deletion requirement you can delete the key for the relevant record(s) to immediately render the data unusable in any large backups or long-term archives without having to regenerate them. When your key backup rolls over, which might only be a matter of days or even hours, any old copies of they key also get destroyed and the personal data is, for practical purposes, gone forever.

Obviously there are many edge cases around deleting partial or related records that would limit the usefulness of a simple scheme like this, and obviously it's no use for data storage and processing that was already set up before the GDPR came into effect and didn't have this sort of mechanism designed in, but I suspect there are quite a lot of data controllers that have relatively simple record-keeping requirements where this kind of approach could work well.