Storage Architecture Explained: Block, File, Object, DAS, NAS and SAN

Storage Architecture Explained: Block, File, Object, DAS, NAS and SAN

Storage is one of the foundations of modern IT infrastructure. Databases, virtual machines, application logs, container volumes, websites, backups, analytics platforms, and business documents all depend on reliable storage.

But storage architecture is much more than choosing between an HDD and an SSD.

Modern infrastructure design must consider how block storage, file storage, object storage, DAS, NAS, SAN, RAID, SSDs, NVMe, IOPS, throughput, latency, caching, snapshots, replication, backups, and disaster recovery work together. Pasted markdown

A simple application may appear to use storage like this:

Application
     |
     v
Filesystem
     |
     v
Disk

A production environment can be much more sophisticated:

Applications
     |
     +---------------+---------------+
     |               |               |
     v               v               v
Block Storage    File Storage    Object Storage
     |               |               |
     +---------------+---------------+
                     |
                     v
              Storage Platform
                     |
              Replication Layer
                     |
                  Backups
                     |
              Disaster Recovery

Storage therefore connects directly to server design, databases, virtualization, clustering, high availability, networking, cloud infrastructure, and disaster recovery.

For broader infrastructure context, see Servers & Infrastructure Explained and Virtualization Explained.

What Is Storage Architecture?

Storage architecture describes how an IT system stores, organizes, accesses, protects, replicates, monitors, and recovers data.

A modern data storage architecture must answer questions such as:

• Where is the data physically stored?
• How does an application access it?
• How quickly can it be read or written?
• What happens when a disk fails?
• What happens when a storage controller fails?
• Can another server access the same data?
• Is the data replicated?
• Can deleted or corrupted information be restored?
• Can the system recover if an entire storage platform, data center, or cloud region becomes unavailable?

A basic server may look like:

Application
     |
     v
Operating System
     |
     v
Filesystem
     |
     v
Local SSD

An enterprise architecture may look like:

Applications
     |
     v
Virtualization Cluster
     |
     v
Storage Network
     |
     v
Storage Cluster
     |
     +-- SSD Performance Tier
     +-- Capacity Tier
     +-- Snapshots
     +-- Replication
     +-- Backup
             |
             v
        Recovery Site

There is no universally correct architecture.

A transactional database may prioritize very low write latency, while a video archive may prioritize capacity and cost. The storage design should therefore start with workload requirements rather than a specific product or vendor. Pasted markdown

Understanding the Storage I/O Path

When an application writes data, that operation may pass through several layers.

Application
     |
     v
Operating System
     |
     v
Filesystem
     |
     v
Block Layer
     |
     v
Device Driver
     |
     v
Storage Controller
     |
     v
Physical Storage

Network storage adds even more components:

Application
     |
     v
Filesystem / Storage Client
     |
     v
Network Protocol
     |
     v
NIC
     |
     v
Network
     |
     v
Storage Controller
     |
     v
Physical Media

This explains why a storage-performance problem is not always a disk problem.

Latency may originate from:

• The application
• Filesystem
• Operating system
• Hypervisor
• Network
• Storage queue
• Controller
• Replication process
• Physical media

For network-attached storage, understanding Computer Networking Explained and TCP/IP Explained is especially useful because technologies such as NFS, SMB, iSCSI, and cloud storage services depend on network connectivity. Pasted markdown

Volatile vs Persistent Storage

One of the first distinctions in architecture is between volatile and persistent data.

RAM is generally volatile:

Power Off
   |
   v
RAM Data Lost

Persistent storage retains information after power is removed:

SSD / HDD
   |
   v
Power Off
   |
   v
Data Remains

Applications frequently use both.

Application
     |
     +-- RAM
     |     Temporary state
     |
     +-- Persistent Storage
           Durable state

This distinction is especially important for databases, virtual machines, and containerized applications. Pasted markdown

Block vs File vs Object Storage

Three of the most important storage models are:

Block storage

File storage

Object storage

They solve different problems.

Block Storage

Block storage divides capacity into individually addressable blocks.

Block Device
     |
     +-- Block 0001
     +-- Block 0002
     +-- Block 0003
     +-- Block 0004
     +-- ...

At this layer, the storage platform does not necessarily care whether the bytes belong to:

database.db
photo.jpg
server.log

A filesystem or database structure can then organize those blocks.

Files
  |
  v
Filesystem
  |
  v
Block Device

Block storage is commonly used for:

• Operating-system disks
• Virtual-machine disks
• Database volumes
• Transaction logs
• Applications requiring predictable low-level I/O

File Storage

File storage organizes information into files and directories.

/
+-- home
|   +-- user
|       +-- document.txt
+-- images
|   +-- photo.jpg
+-- backups
    +-- backup.tar

The filesystem tracks information such as:

• File names
• Directories
• Permissions
• Ownership
• Timestamps
• File size
• Allocation information

File storage may be local or shared through protocols such as NFS and SMB.

For practical Linux filesystem administration, see Linux Server Administration.

Object Storage

Object storage uses another model.

Data is stored as independent objects.

Bucket
   |
   +-- Object A
   +-- Object B
   +-- Object C
   +-- Object D

An object can combine:

Object Data
     +
Object Identifier
     +
Metadata

Applications typically interact with object storage through APIs.

It is especially useful for large collections of:

• Images
• Videos
• Website assets
• Logs
• Backups
• Archives
• Data-lake datasets

Object storage is one of the major storage models used in Cloud Computing.

Object Storage Is Not Simply a Filesystem

An object key might appear hierarchical:

images/2026/server-room.jpg

but this does not mean the underlying platform behaves exactly like a traditional POSIX filesystem.

Applications designed around file locking, directory semantics, in-place random modification, or filesystem permissions may need a different architecture.

Block vs File vs Object Storage Comparison

There is no universally superior model.

The correct question is:

Which storage model matches the application’s access pattern, performance, durability, availability, and operational requirements?

The original article makes this block/file/object distinction one of its central architectural decisions. Pasted markdown

DAS vs NAS vs SAN

Storage can also be classified by how it connects to servers.

Direct-Attached Storage — DAS

DAS is storage directly attached to an individual server.

Server
   |
   v
SSD / HDD / NVMe

Common examples include SATA, SAS, and NVMe devices installed directly in a host.

A major advantage is simplicity.

CPU
 |
 v
PCIe / Storage Controller
 |
 v
Storage Device

The I/O path can be short and very fast.

However, local storage creates an availability challenge.

Server A
   |
   v
Local NVMe

If Server A fails, another server may not automatically be able to access that local drive.

Network-Attached Storage — NAS

NAS provides file-level storage over a network.

Server A --\
Server B ---- Network ---- NAS
Server C --/

Common protocols include:

• NFS
• SMB

Clients access files and directories rather than raw storage blocks.

Client
   |
   v
NFS / SMB
   |
   v
Network
   |
   v
NAS
   |
   v
Filesystem
   |
   v
Physical Storage

NAS is frequently useful for:

• Shared directories
• User home directories
• Media repositories
• Backup targets
• Shared application files

Storage Area Network — SAN

A SAN generally provides network-based block storage.

Server A --\
Server B ---- Storage Network ---- Storage Array
Server C --/

The operating system may see the remote resource similarly to a local block device:

/dev/sdb

The host can then create a filesystem, logical volume, or database structure on top of it.

SAN technologies can include:

• Fibre Channel
• iSCSI

A simplified architecture:

Servers
   |
   v
HBAs / NICs
   |
   v
SAN Fabric
   |
   v
Storage Controllers
   |
   v
Storage Pool
   |
   v
SSD / HDD / Flash

SAN architectures have traditionally been important for virtualization, databases, and enterprise block storage. Pasted markdown

DAS vs NAS vs SAN Comparison

One practical question is:

Who manages the filesystem?

With NAS, the storage platform normally manages the filesystem.

With SAN or other block storage, the host often receives a block device and manages the filesystem or application data structure itself.

What Is a LUN?

A Logical Unit Number, or LUN, represents a logical block-storage resource presented by a storage platform.

Example:

Storage Pool
     |
     +-- LUN 01 -> Database Server
     +-- LUN 02 -> Virtualization Cluster
     +-- LUN 03 -> Backup Server

The underlying storage could consist of many disks, flash modules, RAID groups, or storage nodes.

The host receives a logical block device without necessarily needing to understand the physical layout underneath it. Pasted markdown

HDD vs SSD vs NVMe

HDD Storage

Hard disk drives store information magnetically on rotating platters.

Mechanical movement introduces seek latency.

HDDs can still be useful when:

• Capacity matters more than latency
• Sequential performance is sufficient
• Cost per unit of storage is important

SSD Storage

SSDs use flash memory instead of rotating media.

Because there is no mechanical seek operation, SSDs can provide dramatically better random I/O performance than HDDs.

Typical workloads include:

• Databases
• Virtualization
• Application servers
• Frequently accessed datasets

NVMe Storage

NVMe is designed for high-performance non-volatile storage and is commonly used with PCI Express.

CPU
 |
 v
PCIe
 |
 v
NVMe SSD

NVMe can support substantial parallelism and low-latency I/O.

However, interface type alone does not determine workload performance.

You still need to evaluate:

IOPS + throughput + latency + I/O size + workload pattern + queue depth. Pasted markdown

Storage Performance

Storage performance cannot be represented accurately with one number.

A complete performance analysis should consider:

• IOPS
• Throughput
• Latency
• I/O size
• Random vs sequential access
• Read/write ratio
• Queue depth
• Concurrency
• p95/p99 latency

IOPS, Throughput and Latency

What Is IOPS?

IOPS means Input/Output Operations Per Second.

If a storage system completes:

20,000 operations

during one second, the workload is approximately:

20,000 IOPS

But “20,000 IOPS” alone tells us very little.

The workload could consist of:

4 KB random reads
8 KB random writes
64 KB sequential reads
70/30 mixed read/write

These workloads can behave very differently.

IOPS and I/O Size

Suppose:

10,000 IOPS

with 4 KB operations.

The approximate data rate is:

10,000 x 4 KB
≈ 40 MB/s

With 64 KB operations:

10,000 x 64 KB
≈ 640 MB/s

The same IOPS figure can therefore correspond to very different throughput.

Storage Throughput

Throughput measures data transferred over time.

Common units include:

MB/s
GB/s

Throughput is especially important for:

• Backups
• Large media transfers
• Bulk imports
• Analytics
• Video processing

Storage Latency

Latency measures how long an individual I/O operation takes.

Application
     |
     | Read
     v
Storage
     |
     | Response
     v
Application

If an I/O completes in two milliseconds, the observed latency is about:

2 ms

For transactional applications, latency can matter more than peak throughput. Pasted markdown

Random vs Sequential I/O

Sequential access reads or writes neighboring blocks:

Block 100
Block 101
Block 102
Block 103

Random I/O accesses scattered locations:

Block 918
Block 17
Block 4102
Block 83

Mechanical HDDs are particularly sensitive to random workloads because the read/write head must physically seek between locations.

SSDs greatly reduce this penalty.

Database workloads often generate substantial random I/O, which is one reason SSD and NVMe platforms can significantly improve database performance.

Writes can also be more expensive than reads because they may involve:

• Journaling
• Parity
• Replication
• Metadata updates
• Flash garbage collection

For this reason, storage benchmarks should resemble the actual application workload. Pasted markdown

Queue Depth and Tail Latency

Applications can issue multiple I/O requests simultaneously.

Request 1 --\
Request 2 ---\
Request 3 ---- Storage
Request 4 ---/

Modern NVMe devices are designed to handle significant parallelism.

But very deep queues can also increase latency.

A benchmark showing enormous IOPS with unrealistic queue depth may not represent a normal application.

Average latency can also hide serious problems.

For example:

Average latency = 2 ms

may appear excellent.

But:

p99 latency = 400 ms

means a small percentage of requests are extremely slow.

Those slow requests can still create visible application delays.

Production monitoring should therefore consider latency percentiles rather than only averages. Pasted markdown

RAID Explained

RAID — Redundant Array of Independent Disks — combines multiple storage devices into a logical storage structure.

Different RAID levels use combinations of:

• Striping
• Mirroring
• Parity

to balance capacity, performance, and fault tolerance. Pasted markdown

RAID 0

RAID 0 uses striping.

Disk A        Disk B

Block 1       Block 2
Block 3       Block 4
Block 5       Block 6

It can improve aggregate performance and usable capacity.

But RAID 0 provides no redundancy.

A single member failure can make data unavailable.

RAID 1

RAID 1 uses mirroring.

           Write
             |
        +----+----+
        v         v
      Disk A    Disk B
       Data      Data

If one member fails:

Disk A X
Disk B OK

the remaining copy can continue to provide data.

RAID 5

RAID 5 uses distributed parity.

Disk A       Disk B       Disk C

Data         Data         Parity
Data         Parity       Data
Parity       Data         Data

It generally tolerates one member failure but introduces parity and rebuild overhead.

RAID 6

RAID 6 uses two independent parity values.

Data + Data + Parity P + Parity Q

It can generally tolerate two member failures at the cost of additional capacity and write overhead.

RAID 10

RAID 10 combines mirroring and striping.

              RAID 10
                 |
          +------+------+
          v             v
       Mirror A      Mirror B
       Disk 1/2      Disk 3/4

It is commonly chosen when both redundancy and performance are important.

RAID Is Not Backup

One of the most important rules in storage architecture is:

RAID is not a backup.

Imagine an administrator deletes an important directory:

rm -rf /important-data

A RAID system can faithfully replicate or record the deletion.

The same principle applies to:

• Ransomware
• Filesystem corruption
• Malicious deletion
• Application errors
• Site-level disasters

RAID primarily addresses certain device failures.

Backup addresses another problem:

recovering data from an earlier independent recovery point.

RAID rebuilds can also consume significant I/O and reduce fault tolerance while reconstruction is taking place. Pasted markdown

Storage Replication

Replication maintains additional copies of data on another storage system or location.

Primary Storage
      |
      v
  Replication
      |
      v
Secondary Storage

Replication can support high availability and disaster recovery.

But replication is not automatically equivalent to backup.

If deletion or corruption is replicated immediately, the secondary system can receive the same unwanted change. Pasted markdown

Synchronous Replication

With synchronous replication, another storage location participates before the write is acknowledged according to the platform’s consistency model.

Application
     |
     v
Primary
     |
     v
Secondary
     |
     v
ACK

This can reduce exposure to acknowledged-data loss.

The trade-off is latency.

Long network round trips can directly increase application write latency.

Asynchronous Replication

With asynchronous replication:

Application
     |
     v
Primary
     |
     +---- ACK ---> Application
     |
     v
Replication Queue
     |
     v
Secondary

The application is less affected by remote write latency.

However, replication lag becomes possible.

Recent writes can be lost if the primary fails before the secondary receives them.

Replication design therefore affects the achievable Recovery Point Objective — RPO. Pasted markdown

Snapshots and Backups

A snapshot records storage state at a particular point in time.

Volume
  |
  +-- Snapshot 09:00
  +-- Snapshot 12:00
  +-- Snapshot 15:00
  +-- Current

Snapshots can support:

• Rapid rollback
• Testing
• Cloning
• Fast recovery points

But a snapshot is not automatically an independent backup.

If snapshots share the same platform, administrative account, or failure domain as production, a major incident can affect both.

RAID vs Replication vs Snapshot vs Backup

A resilient architecture normally combines several mechanisms rather than relying on one. Pasted markdown Pasted markdown

Thin Provisioning and Multipathing

Thin Provisioning

Thin provisioning allows logical capacity to exceed immediately reserved physical capacity.

Example:

Physical Storage = 10 TB

Volume A = 6 TB
Volume B = 6 TB
Volume C = 6 TB

Logical Total = 18 TB

This can improve utilization.

But it introduces risk.

If actual consumption approaches physical capacity, writes can fail.

Thin provisioning therefore requires careful monitoring and forecasting.

Multipathing

Multipathing provides multiple storage paths.

Instead of:

Server
  |
Switch
  |
Storage

use:

             +-- Switch A --+
Server ------+              +---- Storage
             +-- Switch B --+

If one path fails, another may remain available.

True redundancy requires independent failure domains.

Two cables attached to the same switch do not eliminate that switch as a single point of failure. Pasted markdown

Storage Caching

Caching places frequently accessed data on faster storage.

Application
     |
     v
Fast Cache
     |
     v
Primary Storage

A cache may use:

• RAM
• SSD
• NVMe

Read Caching

Read Request
     |
     v
   Cache
   /   \
 HIT   MISS
 |      |
Data   Backend

A high cache-hit ratio can reduce backend load and application latency.

Write-Through vs Write-Back

With write-through caching, persistent storage participates before completion according to the platform’s acknowledgement behavior.

With write-back caching:

Application
     |
     v
Protected Fast Cache
     |
     +---- ACK
     |
     v
Backend Storage

performance can improve substantially.

However, uncommitted cached writes must be protected against controller or power failure. Pasted markdown

Filesystems and Journaling

Block storage becomes useful to general applications through filesystems.

Applications
     |
     v
Filesystem
     |
     v
Block Device
     |
     v
Storage

The filesystem provides:

• File names
• Directories
• Permissions
• Metadata
• Allocation tracking
• Free-space management

Linux infrastructure commonly uses filesystems such as XFS and ext4.

Filesystem Journaling

Many filesystems use journals to improve consistency after an unexpected interruption.

Filesystem Change
       |
       v
     Journal
       |
       v
Main Filesystem

But:

Filesystem journaling is not backup.

It does not provide independent historical copies of data. Pasted markdown

Storage for Virtualization

Storage is central to virtualization.

Hypervisor A --\
Hypervisor B ---- Shared Storage
Hypervisor C --/

Shared storage can allow virtual-machine data to remain accessible as compute workloads move between hypervisors.

A VM’s storage path may be:

Virtual Machine
      |
      v
Virtual Disk
      |
      v
Hypervisor
      |
      v
Datastore / Volume
      |
      v
Storage Platform

This creates many possible bottlenecks.

A problem can originate from:

• Guest operating system
• Hypervisor
• Storage network
• Datastore
• Controller
• Physical media

The original article also highlights the storage noisy-neighbor problem: one VM generating extremely heavy I/O can increase latency for other VMs sharing the same storage pool. Pasted markdown

For compute-side architecture, see Virtualization Explained.

Storage for Containers

Containers are replaceable by design, but important application data may need to persist after a particular container instance disappears.

Container
    |
    X
Removed

Persistent Data
      |
      ✓
Survives

Kubernetes addresses this with storage abstractions such as volumes, PersistentVolumes, and PersistentVolumeClaims.

Pod
 |
 v
PersistentVolumeClaim
 |
 v
PersistentVolume
 |
 v
Storage System

The official Kubernetes Volumes documentation and Persistent Volumes documentation describe these abstractions and how storage can have a lifecycle independent of individual Pods.

This is especially important for stateful applications. Pasted markdown

Database Storage Architecture

Databases are among the most storage-sensitive workloads.

Important characteristics include:

• Latency
• IOPS
• Durability
• Write ordering
• Consistency
• Availability

A database can generate several I/O patterns simultaneously:

• Random reads
• Random writes
• Sequential transaction-log writes
• Checkpoints
• Temporary data
• Compaction
• Backup traffic

That is why simplistic benchmarks are dangerous.

A storage system with excellent sequential throughput may still perform poorly for a latency-sensitive transactional database.

Transaction Logs

Many databases use transaction or write-ahead logs.

Transaction
     |
     v
Transaction Log
     |
     v
Persistent Storage
     |
     v
Data Pages

The database may need important log records to become durable before reporting a transaction as committed.

Storage latency can therefore directly influence transaction latency. Pasted markdown

Cloud Storage Architecture

Cloud computing separates logical storage services from individual physical servers.

A cloud VM may use network-attached block storage:

Cloud VM
   |
   v
Virtual Block Device
   |
   v
Cloud Storage Network
   |
   v
Distributed Storage Platform

To the operating system, the volume may look like a normal disk even though its backend is a distributed platform.

Cloud environments commonly provide several storage models:

Cloud Block Storage

Useful for:

• VM disks
• Databases
• Boot volumes
• Stateful applications

Cloud File Storage

Useful when multiple systems need shared filesystem semantics.

Cloud Object Storage

Useful for:

• Media
• Archives
• Backups
• Static assets
• Logs
• Data lakes

A major architectural advantage is that compute and storage can often scale independently.

For broader context, see Cloud Computing Explained and AWS vs Azure vs Google Cloud. The source article specifically positions cloud storage as a distributed abstraction separate from individual physical hosts. Pasted markdown

Unified Storage Architecture

A unified storage architecture aims to provide multiple storage-access models from a consolidated platform.

For example, a platform may expose:

Storage Platform
      |
      +-- Block Access
      |
      +-- File Access
      |
      +-- Object Access

The important point is that “unified” does not mean block, file, and object storage become identical.

They still expose different semantics to applications.

Unified platforms can simplify infrastructure management, but architects still need to select the correct access model for each workload.

Availability vs Durability

These terms are related but different.

Availability asks:

Can the application access the data right now?

Durability asks:

Will the data remain intact despite failures over time?

A service can temporarily become unavailable while all the data remains intact.

Data Exists ✓
Service Reachability ✗

That is primarily an availability problem.

Permanent destruction of data is a durability problem.

A strong storage architecture considers both. Pasted markdown

Failure Domains

Suppose three copies of a dataset exist:

Copy A
Copy B
Copy C

At first, that looks resilient.

But if every copy exists inside the same chassis:

Storage Chassis
   +-- Copy A
   +-- Copy B
   +-- Copy C

a chassis failure can affect every copy.

A better architecture separates copies:

Storage Node A -> Copy A
Storage Node B -> Copy B
Storage Node C -> Copy C

At larger scale, failure domains may include:

• Drives
• Controllers
• Chassis
• Racks
• Data centers
• Availability zones
• Regions

Storage resilience therefore depends not merely on the number of copies, but on where those copies exist. Pasted markdown

Erasure Coding

Distributed storage platforms may use erasure coding rather than storing several full replicas.

A simplified representation:

Original Data
      |
      v
+-----+-----+-----+-----+-----+
|     |     |     |     |     |
D1    D2    D3    P1    P2

Data and parity fragments can be distributed across different storage nodes or failure domains.

If some fragments are lost, the system may reconstruct the original data as long as enough fragments remain.

This can improve storage efficiency compared with keeping multiple complete copies, although it introduces additional computational, network, and recovery complexity. Pasted markdown

Storage Security

Storage frequently contains some of an organization’s most valuable information.

Security controls should therefore address:

• Encryption
• Authentication
• Authorization
• Network segmentation
• Logging
• Backup protection
• Key management
• Secure deletion

For broader context, see Network Security Basics and Firewalls Explained.

Encryption at Rest

Plaintext
    |
    v
Encryption
    |
    v
Stored Ciphertext

Encryption creates an additional recovery dependency.

Encrypted Backup ✓
Encryption Key ✗

can effectively result in:

Recoverable Data ✗

Key management therefore belongs in disaster-recovery planning.

Encryption in Transit

Network-attached storage moves data through a network path.

Server
   |
   v
Network
   |
   v
Storage

Where supported and required, encryption in transit can protect that communication.

Least Privilege

An application should receive only the access it requires.

Prefer:

Application A
      |
      v
Bucket A
Read + Write

over unnecessary global administrative access.

A compromised application should not automatically expose every backup, volume, share, or object repository. Pasted markdown

Storage Monitoring and Troubleshooting

Monitoring storage means much more than checking free disk space.

Important metrics include:

• Capacity
• Growth rate
• IOPS
• Throughput
• Latency
• Queue depth
• Read/write errors
• Device health
• RAID status
• Replication lag
• Snapshot status
• Backup status
• Path health
• Cache efficiency

The surrounding infrastructure must also be monitored.

A perfectly healthy storage platform is still unavailable if every network path to it fails. Pasted markdown

Linux Storage Troubleshooting

Display filesystem capacity:

df -h

Display block devices:

lsblk

Inspect device metadata:

blkid

Check inode usage:

df -i

Inspect kernel messages:

journalctl -k

Inspect extended I/O statistics when sysstat is available:

iostat -xz 1

For broader Linux administration, see Linux Server Administration.

Disk Space Exhaustion

If a filesystem reaches:

100% Used

applications may fail to create:

• Logs
• Temporary files
• Database records
• Cache entries
• Uploads
• Package updates

But available bytes are not the only resource.

Inodes can also become exhausted.

df -i

A system can therefore have free storage capacity but still be unable to create another file.

Deleted but Open Files

A Linux process may continue holding a deleted file open.

Where lsof is available:

lsof +L1

can help identify removed files still consuming storage.

Troubleshooting High Storage Latency

Do not assume the physical disk is immediately responsible.

Check the full path:

Application
     |
     v
Database
     |
     v
Filesystem
     |
     v
Operating System
     |
     v
Hypervisor
     |
     v
Network
     |
     v
Storage Platform

Possible causes include:

• Device saturation
• RAID rebuild
• Backup activity
• Snapshot operations
• Network congestion
• Storage controller issues
• Replication load
• Noisy neighbors
• Excessive application concurrency

The source article explicitly treats storage troubleshooting as a cross-layer problem. Pasted markdown

Replication Lag

Primary
   |
   v
Replication Queue
   |
   | Growing
   v
Secondary

The secondary can remain online while becoming increasingly stale.

If it is part of disaster recovery, the real RPO is becoming worse.

Replication lag should therefore be monitored as a reliability metric. Pasted markdown

Capacity Planning and Tiering

Capacity planning should account for much more than today’s dataset.

Suppose an environment contains:

8 TB

and grows by:

500 GB/month

After twelve months, the dataset alone could approach:

14 TB

But production architecture may also require capacity for:

• Snapshots
• Replicas
• RAID overhead
• Backups
• Rebuilds
• Logs
• Temporary data
• Future growth

Therefore:

Raw Capacity

is not equal to:

Usable Production Capacity

Storage Tiering

Not every dataset needs expensive high-performance storage.

Tier 1
NVMe / High Performance
     |
     v
Tier 2
SSD / General Workloads
     |
     v
Tier 3
Capacity Storage
     |
     v
Archive / Object Storage

Data can also be categorized as:

Hot  -> Frequently accessed
Warm -> Occasionally accessed
Cold -> Rarely accessed

The architecture should match performance and cost to actual access patterns. Pasted markdown

Production Storage Architecture

A mature environment may combine the technologies discussed above:

                          Applications
                               |
             +-----------------+-----------------+
             |                 |                 |
             v                 v                 v
          Web Tier         Database         File Services
             |                 |                 |
             v                 v                 v
       Object Storage    Block Storage      File Storage
             |                 |                 |
             +-----------------+-----------------+
                               |
                               v
                        Storage Platform
                               |
                 +-------------+-------------+
                 |             |             |
                 v             v             v
             Storage A     Storage B     Storage C
                 |             |             |
                 +-------- Replication ------+
                               |
                               v
                           Snapshots
                               |
                               v
                            Backups
                               |
                               v
                     Independent Backup
                               |
                               v
                     Recovery Environment

This architecture separates responsibilities:

• The application receives the correct storage model.
• The storage platform provides redundancy.
• Replication supports availability.
• Snapshots provide fast point-in-time recovery.
• Backups provide historical recovery.
• Independent copies protect against larger disasters.

The source article presents this layered architecture as the mature end state of the concepts discussed throughout the guide. Pasted markdown

Choosing Storage by Workload

Different workloads naturally favor different storage architectures.

These are design tendencies, not absolute rules.

The application’s requirements remain the deciding factor. Pasted markdown

A Practical Storage Design Process

Do not begin with:

Which storage product should we buy?

Begin with:

What does the workload need?

Ask:

• What data are we storing?
• How will applications access it?
• What IOPS are required?
• What throughput is required?
• What latency is acceptable?
• How much capacity is needed?
• How quickly will the dataset grow?
• What availability is required?
• What durability is required?
• What are the RPO and RTO targets?
• What are the security requirements?

Only after these requirements are understood should a storage technology be selected. Pasted markdown

Storage Architecture Best Practices

A reliable storage architecture should follow several principles:

• Select block, file, or object storage according to application semantics.
• Monitor latency together with throughput and IOPS.
• Design redundancy around independent failure domains.
• Treat RAID as redundancy, not backup.
• Treat replication primarily as an availability and DR technology.
• Maintain independent backups.
• Test restoration procedures.
• Protect storage using least privilege.
• Use encryption where appropriate.
• Protect encryption keys.
• Monitor thin-provisioned capacity.
• Monitor replication lag.
• Plan capacity before storage reaches exhaustion.
• Match storage tiers to actual access patterns.
• Design storage and disaster recovery together rather than as unrelated projects.

These recommendations reflect the best-practice conclusions of the original article. Pasted markdown

Frequently Asked Questions

What is storage architecture?

Storage architecture defines how an IT environment stores, organizes, accesses, protects, replicates, monitors, and recovers data.

What is block storage?

Block storage exposes individually addressable blocks, commonly presented to an operating system as a disk or logical volume.

What is file storage?

File storage organizes data into files and directories and can be accessed locally or through protocols such as NFS and SMB.

What is object storage?

Object storage stores data as objects containing data, identifiers, and metadata, commonly accessed through APIs.

What is DAS?

DAS means Direct-Attached Storage. It is directly connected to an individual host.

What is NAS?

NAS means Network-Attached Storage. It normally provides file-level access across a network.

What is SAN?

SAN means Storage Area Network. It commonly provides network-based block storage to servers.

What is the difference between NAS and SAN?

NAS generally exposes files and directories.

SAN infrastructure normally presents block devices that hosts can format and manage.

What does IOPS mean?

IOPS means Input/Output Operations Per Second.

However, IOPS should always be interpreted together with I/O size, latency, queue depth, read/write ratio, and access pattern.

Is higher IOPS always better?

No.

A large IOPS result obtained with unrealistic queue depth or a different I/O size may not represent actual application performance.

What is storage throughput?

Throughput measures how much data is transferred during a period of time, often expressed in MB/s or GB/s.

What is storage latency?

Storage latency measures how long an I/O operation takes.

What is RAID?

RAID combines multiple storage devices using techniques such as striping, mirroring, or parity to provide different performance, capacity, and redundancy characteristics.

Is RAID a backup?

No.

RAID may protect against certain device failures but does not provide independent historical recovery from deletion, ransomware, corruption, or many larger failures.

RAID 5 vs RAID 6: what is the difference?

RAID 5 normally uses one distributed parity scheme and generally tolerates one member failure.

RAID 6 uses two parity values and generally tolerates two member failures, at the cost of additional capacity and write overhead.

What is RAID 10?

RAID 10 combines mirroring and striping.

It can offer strong performance and redundancy while sacrificing usable capacity for mirrored copies.

What is storage replication?

Replication copies data between storage systems or locations to support availability or disaster recovery.

What is synchronous replication?

Synchronous replication requires the relevant remote storage operation to participate before the write is acknowledged according to the storage platform’s consistency behavior.

What is asynchronous replication?

Asynchronous replication allows the primary operation to complete before the secondary necessarily catches up, reducing the impact of remote latency while introducing replication lag.

Is a snapshot a backup?

Not automatically.

A snapshot can provide an excellent point-in-time recovery mechanism, but if it shares the same storage platform or failure domain as production, it may not provide sufficient independent protection.

What is thin provisioning?

Thin provisioning creates logical storage capacity without immediately reserving all corresponding physical capacity.

What is multipathing?

Multipathing creates multiple I/O paths between a host and storage so the loss of one path does not necessarily interrupt storage access.

Which storage is best for databases?

Transactional databases often benefit from durable, low-latency block storage, but the correct choice depends on the database engine, workload, availability design, consistency model, and recovery requirements.

Which storage is best for images and videos?

Object storage is frequently well suited for large collections of images, videos, archives, and static content.

What storage should Kubernetes use?

Kubernetes can consume several storage types. Stateful applications commonly use PersistentVolumes provisioned by an appropriate storage platform or StorageClass. The official Kubernetes Persistent Volumes documentation explains the abstraction in more detail.

The FAQ above preserves the primary questions and answers covered in the source article while grouping them under the streamlined article structure. Pasted markdown

Conclusion

Storage architecture is much more than:

HDD
vs
SSD

A production platform must answer much larger questions.

How is the data accessed?

How quickly must storage respond?

How much capacity is required?

What happens when a disk fails?

What happens when a controller fails?

What happens when a network path fails?

What happens when an entire storage platform fails?

Can another server access the data?

Can corrupted or deleted information be recovered?

What happens if the data center or cloud region becomes unavailable?

How are backups protected?

The first major architectural choice is often:

Block
vs
File
vs
Object

Connectivity introduces:

DAS
vs
NAS
vs
SAN

Performance introduces:

IOPS
+
Throughput
+
Latency
+
I/O Size
+
Queue Depth

Resilience introduces:

RAID
+
Replication
+
Multipathing
+
Failure Domains

Recovery introduces:

Snapshots
+
Backups
+
Independent Copies
+
Disaster Recovery

Security adds:

Encryption
+
Authentication
+
Least Privilege
+
Network Segmentation
+
Key Management

A mature architecture eventually becomes:

Application
     |
     v
Correct Storage Model
     |
     v
Redundant Storage
     |
     v
Replication
     |
     v
Snapshots
     |
     v
Independent Backup
     |
     v
Disaster Recovery

The most important principle is that storage redundancy, storage availability, and data recoverability are different problems.

RAID can provide redundancy.

Replication can improve availability.

Snapshots can provide rapid point-in-time recovery.

Backups can provide historical recovery.

Independent or immutable copies can protect against incidents that affect production and ordinary replicas simultaneously. This layered distinction is also the central conclusion of the original article. Pasted markdown

To continue building the infrastructure cluster, see Servers & Infrastructure Explained, Virtualization Explained, Cloud Networking Explained, Linux Server Administration, Network Security Basics, Cloud Computing Explained, and AWS vs Azure vs Google Cloud.