The InfoSec Blog

Linux Archive file systems – ext3 vs reiser vs … ?

Posted by Anton Aylward

So what's the best file system to use for archiving and data storage rather than the normal usage?

Won't that depend on ...

a) the nature of the archive files

If this is simply to be a 'mirror' of the regular file system, a 1:1
file mapping then there is no need for some specific optimizations as there would be if, for example, each snapshot were to be a single large file, a TAR or CPIO image say. You then have to look at what you are archiving: small files, large files .... Archiving mail a mbox is going to be different from archiving as maildir. For example the later is going to consume a LOT of inodes and that affects how one would format a ext2, est3 r ext4 file system but not be relevant on a ReiserFS or BtrFS.

b) the demand for retrieval from the archive

This is actually a can of worms. You might not think so at first but I've seen businesses put out of service because their 'backup' indexing was inadequate when the time came to retrieve a specific archive file of a specific date, as oppose to restore the whole backup. You need to be driven by your business methods here and that in turn will determine your indexing and retrieval which will determine your storage format.

Its business drive, not technology driven. Why else would you be archiving?

Now while (b) is pretty much an 'absolute', (a) can end up being flexible. You HAVE to have a clear way of retrieval otherwise your
archive is just a 'junk room' into which your file system overflows.
That (a) can be flexible also means that the optimization curve is not clearly peaked. Why else would you be asking this question? What's the worst situation if you choose ReiserFS rather than extN? The size of the file system? The number of inodes?

But if your indexing broken or inadequate you've got a business problem.

 

Risk Analysis Makes No Sense … does it?

Posted by Anton Aylward

Shows the difference between systematic and un...
Image via Wikipedia

Take a look at this article.
http://www.zdnet.com/blog/security/security-engineering-broken-promises/6503

You're back?  What did you think of it?

OK, now look again, scroll down the section titled "Risk Management".  It picks up on a number of themes I've discussed and has this interesting observation:

Prioritization of security efforts is a prudent step, naturally. The problem is that when risk management is done strictly by the numbers, it does deceptively little to actually understand,  contain, and manage real-world problems. Instead, it introduces a dangerous fallacy: that structured inadequacy is almost as good as adequacy, and that underfunded security efforts plus risk management are about as good as properly funded security work.

Guess what? No dice:

The author goes on to illustrate a number of ways that the approach we as the InfoSec community have preached and practised makes no sense.