The Hard Drive is a Consumable: Designing for Failure

It is 3:00 AM on a Tuesday. The snow is piling up outside your office in Oslo, but you are sweating. Why? Because /var/log/messages just spat out a SCSI error, your load average has spiked to 50.0, and your dedicated server provider isn't answering the phone. Your database is corrupted because a single SATA drive decided to seize up.

Welcome to the reality of cheap hosting.

In 2010, we are seeing a massive shift toward virtualization—what marketing teams are starting to call the "Cloud." But abstraction does not eliminate mechanical failure. If your Virtual Private Server (VPS) lands on a host node with a single hard drive or a degraded array, your data is effectively playing Russian Roulette. At CoolVDS, we treat storage as the foundation of stability, not a bulk commodity.

The RAID 5 Trap vs. The RAID 10 Standard

Many hosting providers in Europe are currently racing to the bottom on price. To offer you "Unlimited Disk Space" for $5/month, they cut corners. The most common technical sin is the use of RAID 5 (striping with parity) on large 1TB or 2TB SATA drives.

Here is the math problem they ignore: Rebuild times.

If a 2TB drive fails in a RAID 5 array, the rebuild process involves reading every single bit from the remaining drives to calculate the missing data. In 2010, with standard 7200 RPM drive speeds, this rebuild can take days. During that time, performance degrades by 30-50%, and if a second drive fails (a common occurrence due to the intense read stress during rebuild), the entire array is lost. Total data loss.

This is why CoolVDS strictly enforces RAID 10 architectures.

• Redundancy: We mirror the data first. If a drive fails, we have an exact copy ready to go. No parity calculations needed.
• Performance: We stripe the mirrors. This aggregates the write speed of multiple disks.
• Safety: We can survive multiple drive failures, provided they aren't in the same mirror pair.

Pro Tip for Sysadmins: Never assume your provider's partition alignment is correct. If you are running a database on a VPS, ensure your filesystem aligns with the underlying storage blocks. On CentOS 5, this can be tricky, but it's crucial for avoiding the "read-modify-write" penalty.

Latency: The NIX (Norwegian Internet Exchange) Factor

We often hear developers say, "I'll just host it in the US, it's cheaper." They forget the speed of light.

If your customer base is in Norway, hosting in Texas introduces a 120ms+ round-trip latency. For a static brochure site, that is annoying. For a Magento e-commerce store making dozens of database calls per page load, it is fatal. The TCP handshake overhead alone will kill your conversion rates.

Hosting locally in Norway, connected to NIX, keeps your latency under 10ms for local users. Furthermore, there is the legal aspect. Under the Personal Data Act (Personopplysningsloven) and the EU Data Protection Directive (95/46/EC), you are responsible for where your customer data physically resides. Using a US-based "cloud" bucket might seem convenient until Datatilsynet (The Norwegian Data Protection Authority) comes knocking asking about Safe Harbor compliance.

CoolVDS infrastructure is physically located in Oslo. Your data stays under Norwegian jurisdiction. Simple.

Benchmarking Your Storage: Don't Guess, Verify

How do you know if your current VPS provider is stealing IOPS from you? You benchmark it. But do not use simple file copy commands which can be cached in RAM.

Use dd with the fdatasync flag to force a physical write to the disk. Here is a quick test you can run on your server right now:

Interpreting the results (2010 Standards):

• < 10 MB/s: The host node is overloaded or using a single old IDE drive. Move immediately.
• 30-50 MB/s: Standard shared hosting performance. Acceptable for low traffic.
• > 80 MB/s: Respectable Enterprise RAID performance.
• > 200 MB/s: You are likely on a CoolVDS high-performance node with SAS 15k RPM drives or cached storage.

Optimizing Linux for Disk I/O

Even with fast storage, default Linux settings can slow you down. If you are managing your own CoolVDS instance, open your /etc/fstab and look at your mount options.

By default, Linux records the "access time" (atime) every time a file is read. On a high-traffic web server reading thousands of PHP files and images, this generates thousands of unnecessary write operations.

Change this:

To this:

Then remount:

This single change can reduce disk I/O load by 10-20% on read-heavy servers.

The Verdict

Technology is moving fast. We are hearing rumors of Solid State Drives (SSDs) entering the enterprise market soon, which could revolutionize random I/O performance. But until that technology matures and becomes affordable, the gold standard remains high-speed SAS drives in a RAID 10 configuration.

Do not let your application fail because you trusted a $4/month host with your data. Infrastructure is not the place to gamble.

Ready to secure your data? Deploy a RAID 10-backed CoolVDS Xen VPS in Oslo today and stop worrying about disk failure.