Power brown outs

Posted by: GaryISL on 25 October 2014

So winter is coming and a number of our power stations seem to be a bit ill. I've read that the chances of brown outs occurring this winter are significantly higher than last. I run a QNAP TS-212 streaming to my SuperUniti. I keep x2 3TB drives in a RAID one configuration, with two spare images not more than 12 months old off site, and with a local up-to-date USB backup on site. The NAS is protected by a UPS/surge protector which provides about 10/20 minutes of power if the worst happens. 

 

The main thing worrying me is the NAS being on when I'm not in (it's programmed to be on during evenings and all weekend) and that a brown out occurs when I can't manually shut it down. The hardware won't support automatic shut down unfortunately. 

 

So all in all I think I'm fairly well protected, but would anyone have any other suggestions, specifically around the issue of brown outs?

Posted on: 25 October 2014 by Mike-B

OK it might not support a complete shut down,  but what about go to "safe" mode. 

My Synology & APC (UPS) is USB connected & when power fails the UPS signals the NAS to go to safe mode & from there its safe go off with no power.

Posted on: 25 October 2014 by Simon-in-Suffolk

I agree with Mike - tell you NAS to power down when the UPS nears exhaustion. Most quality NASs I have come across can do this - and this is what I do with my Netgear NASs powered by a single APC UPS.

Simon

 

Posted on: 25 October 2014 by GraemeH

'Power Brown outs' - what happens when you accidentally switch on 'Statement' at full volume.

 

G

Posted on: 25 October 2014 by dayjay
Originally Posted by GraemeH:

'Power Brown outs' - what happens when you accidentally switch on 'Statement' at full volume.

 

G

You order your new speakers? 

Posted on: 25 October 2014 by Huge

Most (but not all) current disk operating systems now run in a constantly stable mode, and power outages rarely result in lost data (other than new data being written to the disk at the time of the outage).  Furthermore, hard disk drives themselves are designed to make sure that no pulse is sent to the read/write head on power down or power up, thus avoiding corruption of existing data.

 

In practice this means that an unexpected shut-down will normally have little or no consequence (that is other than the OS running a self diagnostic, usually including the disk, on restart).

Posted on: 25 October 2014 by Harry

... unless the HDD has been spiked. What we refer to in the UK as power cuts can be accompanied by surges and fluctuations which are particularly good at killing HDDs. It can also happen when the power is restored.

Posted on: 26 October 2014 by Simon-in-Suffolk

Also some NASes have optional performance enhancements that use buffering, such that certain data can remain in a buffer state until written to the disk speeding up write operations.. RAID journal logging is an example of this. Therefore a power outage can cause a corrupt RAID disk system, sometimes fixable by rebuilding the RAID but not always.

Before I used a UPS I had expierienced one zapped PSU and damaged disk (for the reasons Harry describes above) and often required lengthy checks after power outages (and this having disabled the optimisations mentioned above)... Since I have had a UPS I have not had one issue and run with full optimisations.

Simon

 

Posted on: 26 October 2014 by Huge

After Simon's post,

 

It has occurred to me, that while desk-top HD drives are protected from sudden power loss and surges, some NAS drives may be designed assuming there is a UPS in the system, so may not have this protection.  Select your drives accordingly.

 

Similarly if the NAS device itself is designed for use with a UPS, then operating without one is a risk - either fit a UPS or select a NAS device designed for home use that doesn't assume the presence of a UPS.  Many RAID systems that can operate above RAID1 do assume a UPS is present.

 

 

Storage maintenance subsystems should always be designed to use transactional storage protocols. If the file system is transactional it should pass the ACID test; if not the system isn't competent.

 

 

In term of system writes the (shortened) sequence should be functionally similar (there are other ways) to this...

1  Data inserted into buffer

2  Data written to transaction data journal on disk

3  File Directory switched to secondary MFT (atomic operation)

4  Primary MFT for file marked as incomplete

5  Primary MFT updated to reflect new disk sectors for file then marked

6  Primary MFT for file marked as complete

7  File Directory switched back to Primary MFT (atomic operation)

8  Journal MFT entries updated

9  Secondary MFT updated to reflect new disk sectors for file (deferred operation).

All the above can be implemented as 'write behind' without affecting the durability of the system.

 

Incomplete writes to the transaction data journal do not affect the data in the files, and the journal is flushed on recovery.  Before 7, you recover the old file data, after 7 you get the new file data.  There is no ambiguity.

 

At all times, after recovery what you have is either the original file untouched, or the new file completed.  At no time do you have inconsistent data after recovery.

 

 

If you get corrupted data or a corrupted disk then you've had a system failure (which is always a risk with any system during the stress of an unexpected power cycle).

 

(Or you were using a system designed specifically for use with a UPS without one, which is the fault of whoever specified the system).

Posted on: 26 October 2014 by Huge

I also forgot to mention, when not using a higher order RAID configuration you should avoid drives that default to the TLER mode.