Neither should happen. You never actually delete rows from your tables. You mark them as deleted, sure, but the data needs to be able to come back. Space is cheap, there are simply very few cases where outright deletion from a DB table is warranted.
I have a hard time believing Flickr would make a mistake like this. I agree with you - odds are if they actually let an engineer loose on this problem it'll be licked with a DB backfill in 20 minutes.
Consider how deep this rabbit hole goes. If expunging any copies of copyrighted data were strictly necessary, then:
What of data existing on backup media? Should those be re-hydrated, the target data expunged, and then recreated in abridged form?
What of data existing in various content caches (such as memcached)? Should all of those systems be flushed of any possible contaminant?
What of the actual data on physical media? Deleting a file on any modern form of media does not expunge the data, it merely unlinks the location of the data on disk from the file system directory. It might be necessary, depending on filesystem and drive type, to scan all of the unused sectors on an entire disk to find out if the target data or any part of it existed.
As you see, quite quickly you get into absurdities. Nobody goes to that much trouble to delete merely copyright infringing data.
I should note that this not true in the case of child porn. Once the feds give them the signal that is completely purged.
This comes with a cost, and it's not a small one. Every single query that ever touches this table, in every single piece of code owned by the company, written or maintained by every single developer (consultant or transient or offshore, none of which ever got training sessions on this requirement) needs to be enhanced to respect "where isDeleted <> true".
It's well understandable if the expected cost to recover after the fact from an occasional issue is smaller than the cost of implementing and maintaining that in the first place.
A sane approach would be to do all your table access via views, and the view definitions have the 'where is_deleted = 0' or whatever. Then your database handles it.
Updates to the view work as well, in pretty much every database system, including MySQL even.
Using views adds a layer of abstraction. That's often a good idea and a step in the right direction, but does come at the cost of increasing the overall complexity of the system. It's an incremental step to the positive, but no revolutionary solution.
http://www.observer.com/2011/tech/flickr-accidentally-delete...
Having seen this kind of effect from a brain drain in the past, I think you're exactly right. Software needs love to survive and this is what it looks like when software and a company becomes unloved.
The lack of a retrieval system could be from a lack of Yahoo wishing to invest in upgrades to the platform in general. The last few years have seen few changes for users beyond geotagging and tagging persons, and competitors (free and otherwise) have stepped far ahead in terms of personalisation and galleries.
I'm very curious to see if Flickr turns into another 'Delicious' situation in a couple years.
The design for a system where you had multiple redundant copies of all the data and could roll back any changes to the data set is different - and would cost a lot more.
EDIT: I don't believe that Yahoo! Flickr does not have a way to recover these things. Or I'm completely wrong.
For a single account it's more of a pita.
Retrieving all the datas associated with one account, put it in a format readable from the production environment and recommit all the changes while dealing with the potential errors and inconstencies seems quite a huge deal.
Messing unrelated data in the process would also be a nightmare.
Of course, not deleting anything from the start wouod be the way.
I can see why Flickr might engineer things this way. Most of their users don't pay (granted, this guy was a pro user). Deleting images when an account is deleted saves money.
What it implies is that the internal tool(s) that the support staff uses was designed to do deletion instead of status changes. I imagine they have a web interface that fires off some backend script which a) runs sql deletes on an account ID and all tables and b) fires off scripts that physically deletes all photos across all servers.
Taking those implications in hand, it points to an incredibly poorly designed system for account management. Some years ago, there was an internal planning meeting where a decision was made to do this. Some people objected and were overruled. The ramifications of that project manager are still sticking it to people to this day.
I have a hard time believing that Flickr would have purposely engineered their systems in the manner I've described. Not impossible, but unlikely.
So I think its more likely that the data is still there, but that customer service has no method to resurrect it. Its probably a mix of internal policies and the lack of devoting a couple of engineers to fix the problem that is causing all of this.