October 10, 2013 at 6:43 am
So I've been commenting in a topic over on Technet, trying to help a guy who needs to ship a copy of his DB to a vendor. Said DB has some sensitive information in it, which he doesn't want the vendor to get. He's working with a copy of the production DB, updated the sensitive info to "placeholder" data, and is now concerned that someone may be able to retrieve the sensitive data from the Transaction Log.
His initial procedure was:
1. Backup the DB
2. Backup the Log
3. Shrink the Log (remember, this isn't the production data!)
4. Backup the DB again (this is the one he'd ship to the vendor)
Now, I didn't think that the backup he'd ship would have anything in the TLog that could potentionally be "read" with a log reader program to recover the sensitive data. Is this incorrect?
If it would be possible to "read" the sensitive information, would something like this avoid the issue:
1. Make the changes
2. Flip the DB to Simple Recovery (he's working with a copy, after all)
3. Issue a CHECKPOINT
4. Wait a while for the lazy writer to flush the log
5. Flip back to Full Recovery
6. Backup the DB (ship this one to the vendor)
I'm not out to prove the other commenters wrong on Technet, just looking to (try to) increase my knowledge.
Thanks,
Jason
October 10, 2013 at 7:06 am
The log file will simply change it status from a 2 (active) to a zero which means that the 1's and 0's are still there. He could do what you are suggesting and also remove extra VLFs and then shrink the log file and that would remove most of the log.
If this isn't the production database why not detach the database and only send the data file(s) and have them recreate the log on their end? Then he won't have to send the log file at all.
October 10, 2013 at 7:49 am
Yeah, the deattach and send the MDF is what's been marked as the answer.
I guess part of me is rather averse to deattach / reattach for some reason, even if it's just as good (or in this case, from all indications, better) than backup / restore.
Personality quirck...
:hehe:
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply