Comments on TorrentFries: Leaving a Host

I'd just like to step in and say Thank you for a g...

2008-10-11T02:19:00.000-07:00

I'd just like to step in and say Thank you for a great writeup on this! There's very few good examples out there and I've recently needed to move out of a dedi I've had for a few years, and unfortunatly can no longer afford. So in my case there's no hard feelings, or dire need to ditch out quickly, but I rest easy knowing that there will be no leftovers for anyone else to pry upon. Just good security practice for anytime this type of situation arises.

I've been keeping up on all of your post's guys, great stuff, and thanks for dedicating the time to do this on the side of running another site. Busy guys.

@checkers, That site you linked not does not back ...

2008-10-10T12:29:00.000-07:00

@checkers,
That site you linked not does not back up what they're saying with any reputation. The challenge they present asks specifically to recover only the names of a file or folder. You can't win the challenge by recovering the data. Doesn't that sound fishy to you?

Also, a quote from Peter Guttman, a developer of data overwrite algorithms: "...it is effectively impossible to sanitize storage locations by simply overwriting
them, no matter how many overwrite passes are made or what data patterns are written."

Crash,First of all, you should know that SRM is no...

2008-10-10T10:04:00.000-07:00

Crash,
First of all, you should know that SRM is not ideal in RAID arrays with stripped disks.

In my experience, and a recent test, deleting a 250 MiB archive maxed out 1 processor, using none of the second processor. Deleting two of such archives used 100% of both processors. I didn't time the operation, so I could be incorrect about the time it takes, but I know that processor affinity is to one at a time on my Ubuntu box.

for clarity;you can run concurrent deletes if the ...

2008-10-10T09:55:00.000-07:00

for clarity;
you can run concurrent deletes if the files are on different disk or arrays. you shouldn't do concurrent deletes on the same array, unless it's a JBOD and you know where the files are physically located, which isn't common.

great blog btw, thanks a lot.

a quicker way would be to run each part of your se...

2008-10-10T09:44:00.000-07:00

a quicker way would be to run each part of your secure removal separately. This works very well if you've got multiple cores or processors.
I disagree and I ran some tests to back it up.

test system: four dual-core 2.2ghz Opteron 875 processors (8 cores total), 4x146GB 10krpm RAID5, 32GiB ram, RHEL AS4 2.6.9-34.ELsmp

test content: eight 20MiB files of /dev/urandom data.

test results: eight srm processes deleting the 8 files concurrently took 675 seconds.
2 concurrent srm processes deleting the 8 files took 366 seconds.
one srm process at a time, deleting the 8 files took 353 seconds.

If the files are on different disks, then you can and should run concurrent deletes, but don't delete more than one file at a time on the same disk. I believe the primary reason is seek latency. If you had a SSD, multithreading like you suggested could be a good idea. But for the most part, SRM is not processor bound.

I've always had great faith in dd, but I'm not a p...

2008-10-10T07:30:00.000-07:00

I've always had great faith in dd, but I'm not a professional data recovery firm and only go by the fact that the government claims that even 38 passes doesn't do a great job. What I've heard is that the only way to stop data recovery is to abrade the disk surface or melt it down. Your source is less than optimal. What reputation do they hold? That site is barren of anything that would lead me to believe anything they write, so I'd have to look into it further.

A 38 pass delete is unneeded and will just take mo...

2008-10-10T02:10:00.000-07:00

A 38 pass delete is unneeded and will just take more time, meaning you can delete less in your limited window. Please see:
http://16systems.com/zero/