Hacker News new | past | comments | ask | show | jobs | submit login

Thank you for saying this, another thing that is ridiculously difficult is to delete specific user from all your backups. This is made even worse if you have multi region backups and cold back ups.

Even a one-year-old start up could have literally thousands of database dumps in different places if they followed best practice of triple redundant daily dumps.




The general recommendation is that if it's too difficult to purge specific users from your backups then:

* Have a clear data retention policy and make sure that all backups have an expiration date.

* Secure your backups with strong encryption to protect user data in the event of a leak.

* Explain it to the user when the account is deleted when the deletion will filter through your backups.

* Guarantee that if a restore is needed, their data will be immediately deleted from the restored system.


How do you keep track of what info needs to be deleted on restore without violating GDPR?


Save "on restore, delete all data sets pertaining to user id 47263".


You should be able to record the deletion request for the life of the backup and purge those records once the backups are deleted (all tied to the same rolling dates)


It sounds to me like this reflects more on the startup's sloppy practices than anything else. Prevalence of this bad practice shouldn't be an excuse for it.


Regular database backups are a bad practice?


Keeping a backup from a year ago when three backups from yesterday are available, is.


I mean, I see the general wisdom of what you're saying, but I think older backups are still good practice. I've seen it take almost a week for a data corruption issue to be noticed. Not crazy to think it'd take even longer, sometimes.


You have a month to delete data under GDPR: https://ico.org.uk/for-organisations/guide-to-the-general-da...

I'd suggest this is a reasonable safety/compliance balance.


No, read again.


They also had 2 years to come up with a way to fix all of that and if they haven’t I don’t think it’s ok for them to be holding that information in the first place. GDPR does give a window for you to remove the data. They could delete the information from the backups over a period of time.


> Thank you for saying this, another thing that is ridiculously difficult is to delete specific user from all your backups.

You have to do very little if you're keeping backups for less than month, simply delete from the DB and wait for backups to age out:

https://ico.org.uk/for-organisations/guide-to-the-general-da...

If you are keeping for longer than a month be prepared to justify that.

> This is made even worse if you have multi region backups and cold back ups.

You should be automating this. I assume you're automating the dumps. Automate the deletion. Deleting three encrypted files off S3 every day really isn't particularly hard. I've written stuff to do this a bunch of times.

> Even a one-year-old start up could have literally thousands of database dumps in different places if they followed best practice of triple redundant daily dumps.

If you have backups sprinkled willy-nilly about the place that you may have lost track of then it shows you have a significant lack of care about my data, and so I don't want you to have it at all.


They'd also be spending a shitload for storing those dumps.

If information is backed up (in a way that it cannot be easily accessible and queried directly from the backup,) and the backups are stored securely, and there is a mechanism/policy (it doesn't have to be a purely technical measure) to replay the deletion in case if the backup is restored, you're going to be fine.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: