DSM-G600, DNS-3xx and NSA-220 Hack Forum

If you are so concerned about a power outage, put it on a UPS.

geno wrote:

Well, actually it is running on an UPS already. But what if the UPS runs out of battery power?

If memory serves there are threads in this forum on getting the dns323 to shutdown gracefully if the mains have failed and ups is running on battery.
lu

There ar also threads here about running ext3 on the DNS.

bq041 wrote:

There ar also threads here about running ext3 on the DNS.

Yep, I have read this thead about some EXT3 testing. It would be nice to have EXT3 running on the DNS-323 instead of EXT2, but until D-Link hasn't officially confirmed that there are not problems bound to using EXT3 anymore I will stick to EXT2.

bscott wrote:

Are you asking if the risk on the DNS-323 is any greater than doing the same thing on a dedicated HD inside a desktop PC?

No. I do know that it's basically the same thing. But there is one tiny difference that I feel needs to be looked at from a different point of view.

Let's assume I have a HD direcly installed in a PC and were to encrypt it by the method I described above (keyword: dm-crypt). I would use the HD's block device which for example is called /dev/sda1. Now, if I loop /dev/sda1 through dm-crypt, another block device will be created, maybe with the name /dev/mapper/crypt-sda1. At this point I can use /dev/crypt-sda1 in exactly the same way as I would use /dev/sda1. The only difference is that /dev/crypt-sda1 produces encrypted writes and decrypted reads. And the most importantl fact ist that any write action will modify the hard disk's content on a per block basis, hence it's called a block device.
So the worst-case would be to lose some blocks that have been recently written to the disk, but eventually not flushed from disk cache yet.

I hope you are still with me.
Ok, now let's take a quick look at the other scenario with my DNS-323.
I create one file on the DNS-323 called "container". It serves as my virtual block device later where I want to put my encrypted data into. The steps from opening the file to reading and/or writing to the opened file are exactly the same actions as my example state above with a HD directly installed in a PC. But this time there is one more "layer" before the data is finally read/written: the container file on the DNS-323 filesystem!

The difference I see here is the following:
On an interruption to write files inside the container may result in corrupted or lost data of those very files involved in this action.
On an interruption to write THE CONTAINER FILE on the DNS-323 filesystem may result in a corrupted file which may also lead to corruption of the container file and therefore complete data loss of everything inside the container.

I have to admit that I'm not fully aware of how those things are working inside. Maybe someone with that depth of knowledge is able to explain if I'm looking for a problem that technically doesn't exist at all.

bscott wrote:

Are you worried about software bugs, hardware failures or transient unpredictable glitches, like an interruption in the network connectivity?

Nope, not at all. Software and hardware failures can always occour and are not part of my problem. Network connectivity might be an issue, although a temporary loss of network connectivity should be nothing more than what would also happen if the DNS-323 is shutdown improperly.

bscott wrote:

By and large the 323 is pretty solid for its intended use, and doing anything else carries a risk comparable to doing the same thing on other platforms.  It's neither immune from, nor more prone to, most of the problems that you may encounter anywhere.  As others will point out to you, nothing will replace having a valid backup of essential files, and no one can predict every source of potential problems.

My DNS-323's primary task is to work as a backup storage, so data loss is not that bad, but reliability is something that makes live much easier. I don't want to rebuild or check the backup unit every 30 minutes, if you know what I mean.

bscott wrote:

If the CPU on the 323 is adequate to keep up with the needs of your scheme, and if you can fully test and validate the setup, I wouldn't worry about some inherent property of the 323 throwing a wrench into your plans.

The CPU of my DNS-323 is not a problem, because the CPU-intensive task (encrypt/decrypt) is handled by my server.

Grettings,
geno

bscott wrote:

I only have a few files that I would even consider encrypting, and more than once I've recovered them thanks to being able to use "dd | strings | grep" (to paraphrase)...

That's a very good argument. Those simple tools wouldn't be much of a help on my systems at the moment.

bscott wrote:

If you really need to encrypt 2 terabytes of data, you may want to look into something a bit more heavy-duty than a $150 box.  But if the files aren't irreplaceable, I don't think your plan is too foolhardy to consider, given a UPS and a bit of luck...

Hm... that's also true. Right now I'm using three full-encrypted Gentoo Linux systems. One of them is my laptop which I carry around quite a lot and thus should definately be secured by encryption. Maybe it's time to reconsider my situation and get rid of the encryption stuff on my two stationary rigs and also leave the DNS-323 unencrypted too. It will definately make things easier this way although I do really like the idea of doing backups the way I wanted to do them. Well, in the end I think that safe (and easily readable!) backups are much more worth than locked down backups where in case of emergency I'm almost unable to recover.

Thanks for the help to let me find out how I should do or better not do this.

Greetings,
geno

Last edited by geno (2008-07-22 04:14:02)

If you decide to continue this project, you might consider to write the data 2 times to 2 different containers sequentially. In case of power or connection loss, only 1 container could be affected. If you want to make it even more robust you could think of using 3 containers for writing and a 2 out of 3 voting mechanism for reading... It's not fast, but might solve your concerns.