6. Storage, Filesystems and Data Protection

Introduction: Storage as an Administrative Responsibility

Linux system administration is often described in terms of processes, users, services, and networks. Yet every one of these functions ultimately depends on storage. A database requires durable blocks, a web service writes logs, a container runtime creates layered filesystems, and a configuration-management system must preserve state. Storage administration therefore concerns more than attaching a disk or creating a directory. It involves designing how data is addressed, organized, protected, expanded, recovered, and eventually retired.

A sound storage design separates several questions that are frequently confused. Where are the physical or virtual blocks located? How are those blocks combined into logical devices? Which filesystem manages files and metadata? Where and how is the filesystem mounted? What happens when a disk fails? How much data can be lost after a disaster? How quickly must service be restored? These questions lead to different technologies: partitioning and block-device tools, Logical Volume Management (LVM), redundant arrays, filesystems, swap, network storage, snapshots, backups, and disaster-recovery procedures.

For DevOps professionals, storage is also an operational and organizational concern. Capacity must be monitored before it becomes an incident; changes should be automated and auditable; backups must be tested rather than merely configured; and recovery objectives must be agreed with application owners. This chapter develops those ideas from the Linux device layer upward to enterprise data-protection strategy.

Learning Objectives

After studying this chapter, the reader should be able to:

1. Explain the relationship among block devices, partitions, filesystems, mount points, and logical volumes.

2. Inspect and configure storage using standard Linux tools.

3. Design and manage LVM volumes, software RAID, swap, and persistent mounts.

4. Compare local, block-based, file-based, and object-oriented network storage.

5. Distinguish capacity, availability, snapshots, backups, and disaster recovery.

6. Develop retention and restoration strategies using recovery-point and recovery-time objectives.

7. Evaluate storage risks, operational trade-offs, and common administrative mistakes.

8. Automate storage checks and recovery exercises safely in DevOps environments.

From Blocks to Files: The Linux Storage Stack

A block device provides addressable units of storage, commonly sectors or logical blocks. Local disks, virtual disks, partitions, logical volumes, and many SAN volumes appear to Linux as block devices. The kernel exposes devices under `/dev`; modern systems commonly use stable identifiers under `/dev/disk/by-uuid` or `/dev/disk/by-id` because names such as `/dev/sdb` may change between boots.

A partition is a region of a block device described by a partition table, usually GPT on contemporary systems. A partition does not itself provide files and directories. It may instead contain a filesystem, a physical volume for LVM, or a RAID member. This distinction is important: formatting the wrong layer can destroy data even when the device name appears plausible.

A filesystem organizes blocks into files, directories, metadata, permissions, timestamps, and allocation structures. Common Linux filesystems include ext4 and XFS. Filesystems differ in allocation design, recovery behavior, resizing capabilities, and workload characteristics. The choice should follow operational requirements rather than habit. For example, XFS is widely used for large filesystems and supports online growth, while ext4 is a general-purpose filesystem with mature repair and resizing tools.

A mount connects a filesystem to the unified Linux directory tree. After mounting a filesystem at `/srv/data`, users and processes access it through that path. Mounting does not copy files; it makes the filesystem namespace available at the selected directory. If a filesystem is mounted over a directory containing existing files, those files are hidden until the mount is removed, a source of frequent administrative confusion.

The storage path can therefore be represented as:

`physical or virtual media → partition or whole device → RAID or LVM layer → filesystem → mount point → application data`

Not every installation contains every layer. A simple server may use a filesystem directly on a virtual disk. An enterprise server may use multipath SAN storage, RAID, LVM, encryption, and a filesystem. Each additional layer offers capabilities but also introduces configuration and failure modes.

Useful inspection commands include:

```bash

lsblk -f

blkid

findmnt

df -hT

du -xsh /var/log/*

```

`lsblk -f` presents devices, filesystems, labels, and UUIDs. `findmnt` shows the active mount hierarchy. `df` reports filesystem-level free space, whereas `du` measures space consumed by files. These measurements are not interchangeable: space may be unavailable because of reserved blocks, filesystem metadata, deleted files still held open by processes, or inode exhaustion.

Capacity, Performance, and Resilience as Separate Design Dimensions

Storage decisions should be evaluated across at least four dimensions. Capacity concerns how much data can be held. Performance concerns throughput, latency, and input/output operations per second. Availability concerns whether data remains accessible during component or service failures. Durability concerns the probability that data remains intact over time. A fast single disk may have good performance but poor availability. A replicated system may tolerate hardware failure but still lose data because an operator deletes it or ransomware encrypts it.

Capacity planning should use trends rather than current utilization alone. A useful operational model records total capacity, used capacity, growth rate, expected bursts, and the threshold at which expansion or remediation must begin. Monitoring only percentage utilization can be misleading on very large volumes; absolute free space and application-specific requirements also matter.

Filesystem capacity is distinct from inode capacity. A filesystem can have free bytes but no free inodes, preventing creation of small files. Conversely, a log-heavy workload may consume blocks rapidly while inode usage remains modest. Both `df -h` and `df -i` should be included in regular checks.

Performance is affected by device latency, queue depth, filesystem behavior, workload locality, synchronization requirements, and network conditions. Benchmark results must be interpreted in the context of the application. Sequential throughput is not a reliable substitute for measuring random reads, random writes, or latency-sensitive transactions.

Resilience requires explicit failure assumptions. RAID can protect against selected disk failures, but it is not a backup. Replication can preserve availability, but replication may also copy corruption or accidental deletion. Snapshots can provide rapid point-in-time recovery, but a snapshot located on the same storage system may be lost with that system. These distinctions form the basis of a defensible data-protection architecture.

Logical Volume Management

LVM introduces an abstraction between physical storage and filesystems. Physical volumes (PVs) are created on disks, partitions, or suitable block devices. PVs are combined into volume groups (VGs), which provide pools of extents. Logical volumes (LVs) are allocated from those pools and appear as block devices on which filesystems or swap can be created.

The principal commands are:

```bash

pvcreate /dev/sdb

vgcreate vgdata /dev/sdb

lvcreate -L 200G -n lvapp vgdata

mkfs.xfs /dev/vgdata/lvapp

mkdir -p /srv/app

mount /dev/vgdata/lvapp /srv/app

```

In production, device identity must be verified before `pvcreate`, since the command initializes metadata on the selected device. `pvs`, `vgs`, and `lvs` provide concise inventory, while `lvdisplay` and `vgdisplay` provide detail.

LVM makes many changes flexible. A volume group can be extended with another physical volume, and an LV can often be enlarged without moving application data. The filesystem must also be grown: `xfs_growfs` is used for a mounted XFS filesystem, while `resize2fs` is used for ext filesystems after the block device has been enlarged. Shrinking is more restrictive and generally requires an unmounted filesystem; XFS cannot be reduced in place. A safe procedure therefore verifies filesystem support, takes a backup, confirms free extents, and rehearses the operation where possible.

LVM snapshots record changed blocks relative to a source LV. They are useful for short-lived consistency points, testing, and backup workflows. A snapshot consumes space as blocks change; if its allocated exception area fills, the snapshot becomes unusable. Snapshots should not be treated as indefinite archives. Thin provisioning and thin snapshots increase flexibility but make over-allocation and monitoring especially important.

Encryption may be placed below LVM, above it, or integrated into a broader storage architecture. Full-disk or volume encryption protects data at rest when media is lost, but it does not protect data while an unlocked system is running. Key storage, recovery keys, boot behavior, and access control must be managed as part of the design.

RAID and the Meaning of Redundancy

RAID combines devices to improve availability, capacity utilization, or performance. Linux software RAID is commonly managed by `mdadm`. RAID 0 stripes data without redundancy and therefore increases failure exposure. RAID 1 mirrors data and can continue after a member failure. RAID 5 uses distributed parity and tolerates one device failure; RAID 6 tolerates two. RAID 10 combines mirroring and striping and is often chosen for workloads requiring good write performance and resilience.

RAID level selection requires consideration of rebuild time, workload, device size, write penalty, and failure probability. A degraded array is operating with reduced protection. Rebuilding can consume substantial bandwidth and may expose a second failure or latent read error. Monitoring should therefore detect degraded states promptly.

Typical commands include:

```bash

cat /proc/mdstat

mdadm --detail /dev/md0

```

RAID protects against particular hardware failures, not against application-level corruption, malware, fire, theft, or administrative error. A backup strategy must exist independently, and at least one backup copy should be isolated from routine production credentials. RAID and LVM can be layered, but the administrator must document the order. For example, RAID beneath LVM provides a pool backed by redundant devices; placing RAID above separate logical volumes has different operational consequences.

Hardware RAID controllers add their own cache, firmware, management interfaces, and failure modes. Neither hardware nor software RAID is automatically superior. The decision should consider observability, portability, controller dependence, performance requirements, and the skills available to the operations team.

Mounts, Filesystem Configuration, and Swap

Temporary mounts made with `mount` disappear after reboot unless they are declared in `/etc/fstab` or managed by a systemd mount unit. An `/etc/fstab` entry commonly contains a device identifier, mount point, filesystem type, options, dump field, and filesystem-check order. UUID-based entries are generally safer than volatile device names:

```text

UUID=xxxx-xxxx /srv/app xfs defaults,nodev 0 0

```

Mount options can enforce security and operational policy. `nodev` prevents device files from being interpreted on the filesystem; `nosuid` disables set-user-ID and set-group-ID behavior; and `noexec` restricts execution, although it is not a complete security boundary. Options must be selected with awareness of application requirements. A careless `noexec` setting can disrupt legitimate software, while an overly permissive mount may increase attack impact.

After editing `fstab`, administrators should validate it before rebooting:

```bash

mount -a

findmnt /srv/app

```

A dedicated filesystem for logs, databases, user data, or container storage limits the impact of one workload consuming all available space. However, excessive fragmentation of storage can increase management overhead. Mount units, automounting, and dependency ordering become relevant in systems whose storage is attached dynamically.

Swap provides virtual memory support. It may be a partition or a file:

```bash

fallocate -l 8G /swapfile

chmod 600 /swapfile

mkswap /swapfile

swapon /swapfile

```

Swap is not a replacement for adequate RAM. It can prevent immediate process termination under memory pressure, but heavy swapping usually causes severe performance degradation. Administrators should monitor memory pressure, swap-in and swap-out activity, and the workload’s latency requirements. The `vm.swappiness` setting influences kernel behavior but should not be changed without measurement.

Network Storage: Sharing, Centralization, and Dependency

Network storage separates compute from storage and may be delivered through file, block, or object interfaces. NFS presents remote filesystems and is common in Linux environments. It supports shared directories but introduces network dependency, authentication concerns, locking behavior, and sensitivity to server or path availability. NFS versions, export permissions, root mapping, and security mechanisms such as Kerberos must be considered in sensitive environments.

iSCSI presents remote block devices to a host. The host can place a filesystem or LVM structure on those devices, but coordination is essential when several hosts access the same block device. A normal filesystem must not be mounted read-write concurrently by multiple hosts unless it is designed for clustered access. Multipath I/O can provide alternate network paths to storage and reduce dependence on one interface or route.

Object storage uses objects, metadata, and APIs rather than a traditional mutable filesystem namespace. It is well suited to backups, artifacts, logs, and large unstructured datasets. Object storage often provides versioning, lifecycle policies, and cross-site replication, but applications must be designed for its API and consistency characteristics. Treating object storage as an ordinary POSIX filesystem can produce poor performance or unexpected semantics.

Network storage changes the failure model. A local disk failure is different from a network partition, authentication failure, stale mount, or storage-controller outage. Applications should define timeout and retry behavior carefully; indefinite retries can convert a storage outage into thread exhaustion and cascading failure.

Snapshots, Backups, and Restoration

A snapshot is a point-in-time representation, usually implemented through copy-on-write metadata. It is valuable for rapid rollback and for obtaining a stable source for backup. A backup is an independent copy intended for recovery. The difference is independence: if production and its snapshot share the same array, a destructive event affecting that array may destroy both.

Backup design begins with business requirements. The recovery point objective (RPO) specifies the maximum tolerable amount of data loss measured in time. The recovery time objective (RTO) specifies the maximum acceptable time to restore service. A system with an RPO of fifteen minutes requires more frequent or continuous protection than one with an RPO of twenty-four hours. A low RTO may require pre-provisioned infrastructure, tested automation, and rapidly accessible backup data.

The familiar 3-2-1 principle recommends at least three copies, on two different media or storage systems, with one copy offline or otherwise isolated. The exact design may extend this principle with geographic separation, immutability, and regular recovery testing. Backup selection should include full, incremental, differential, or synthetic-full approaches according to restore complexity, change rate, bandwidth, and retention requirements.

A robust backup workflow includes application consistency. Simply copying a database’s live files may produce an unusable image. Databases may need native dumps, write suspension, filesystem freeze, or storage-integrated snapshots coordinated with transaction logs. Backup metadata should record what was protected, when, with which encryption and compression settings, and how restoration is performed.

Retention is a policy rather than merely a storage setting. It should reflect legal obligations, contractual requirements, business value, privacy principles, and the cost of keeping data. Retaining everything forever increases exposure and makes discovery and deletion obligations more difficult. Sensitive backups require encryption, controlled keys, access logging, separation of duties, and secure destruction when retention ends.

Restoration must be tested at several levels: individual files, application datasets, complete systems, and perhaps an alternate site. A successful backup job proves only that a process ran; it does not prove recoverability. Restore tests should measure actual RTO, verify data integrity, and document dependencies such as DNS, secrets, certificates, licenses, and network routes.

Disaster Recovery as an Operational Capability

Disaster recovery (DR) is the coordinated restoration of technology and business services after a disruptive event. It includes people, procedures, facilities, dependencies, communications, and technical mechanisms. High availability seeks to reduce interruption during expected component failures; DR addresses larger disruptions and restoration at another location or environment. The two are related but not interchangeable.

A DR plan should identify critical services, owners, dependencies, recovery order, recovery sites, data-protection mechanisms, and decision authority. Strategies range from restoring from backups on newly provisioned infrastructure to maintaining a hot standby that receives replicated data. More rapid strategies generally require greater cost and operational complexity.

Replication can be synchronous or asynchronous. Synchronous replication may reduce data loss but requires suitable latency and coordinated failure handling. Asynchronous replication can operate over greater distances but permits a lag between primary and secondary systems. Failover also introduces split-brain risk, in which two sites believe they are authoritative. Fencing, quorum, explicit promotion procedures, and authoritative naming are essential safeguards.

Runbooks should be executable rather than aspirational. They should contain commands, prerequisites, validation checks, rollback decisions, contact information, and evidence requirements. Exercises may begin as tabletop reviews and progress to controlled technical failovers. Findings must be converted into tracked improvements; otherwise the exercise has little operational value.

An Illustrative Case: Protecting a Payment Platform

Background

A fictional online payment company operates Linux application servers, a relational database, and a reporting platform. Its primary environment uses redundant storage and nightly snapshots. The company has experienced no major outage, but an audit reveals that backups are stored on the same storage cluster as production and that no full restoration has been tested.

Situation and Analysis

The business requires that no more than fifteen minutes of transaction data be lost and that payment service be restored within two hours after a site-level failure. The existing nightly snapshot gives an RPO approaching twenty-four hours and does not satisfy the requirement. RAID protects the storage cluster from selected disk failures, but it does not protect against ransomware, controller failure, or a site disaster. The reporting platform is less critical and can tolerate a longer recovery time.

The operations team maps data dependencies. The database requires transaction-log protection, the application requires secrets and certificates, and the payment service depends on DNS, identity services, and network routing. The team also identifies retention obligations for financial records and a requirement to restrict access to production data in backup environments.

Strategy and Solution

The company retains local snapshots for rapid operational rollback but adds continuous or frequent transaction-log shipping to an isolated secondary environment. Daily encrypted backups are copied to geographically separate object storage with immutability controls. A monthly restoration test rebuilds a database and validates application transactions. A quarterly exercise tests service restoration in the secondary environment.

LVM is used to separate database data, transaction logs, and temporary files, allowing capacity alerts and different backup policies. Filesystem and inode usage are monitored. Backup jobs emit metrics for duration, size, lag, encryption status, and verification outcome. A runbook defines the order of database promotion, secret retrieval, DNS changes, application startup, and reconciliation of transactions.

Outcome

The revised design meets the stated RPO under normal replication conditions and demonstrates an RTO below two hours during a controlled exercise. Testing reveals that an overlooked certificate and an external fraud-detection dependency would otherwise have delayed recovery. These dependencies are added to the runbook and monitoring system.

Learning Points

The case illustrates that storage resilience is layered. RAID supports hardware availability, snapshots support rapid rollback, backups provide independent recovery copies, and DR procedures coordinate service restoration. Requirements should be expressed in RPO and RTO terms, and every claim about recoverability should be supported by evidence from a restoration test.

Risks, Governance, and Common Administrative Errors

The most dangerous storage mistakes are often procedural. Formatting the wrong device, shrinking a filesystem without verifying support, editing `fstab` incorrectly, deleting a logical volume before checking dependencies, or assuming that a completed backup is restorable can cause irreversible loss. Change control should require device identification, peer review for destructive commands, maintenance windows where appropriate, and a verified rollback plan.

Storage also has governance implications. Access to backup data should follow least privilege and separation of duties. Audit records should show who changed mounts, volumes, retention rules, and recovery configurations. Data classification should influence encryption, geographic placement, retention, and deletion. Regulations may require preservation or erasure, and these requirements can conflict; legal and compliance owners must participate in policy decisions.

Automation reduces inconsistency but can magnify errors. Scripts should use strict error handling, validate expected devices and filesystem types, log actions, and avoid assumptions about device names. Infrastructure-as-code can declare volumes, mounts, and monitoring, while configuration management can enforce package and service state. Destructive operations should require explicit approval or an out-of-band safeguard.

Emerging practice increasingly combines immutable backups, policy-driven lifecycle management, storage telemetry, and automated recovery validation. Cloud platforms provide elastic block, file, and object services, but abstraction does not eliminate responsibility: administrators still need to understand snapshots, access policies, regional failure, egress cost, encryption keys, and provider-specific recovery limits. Predictive analytics may assist capacity planning and anomaly detection, but automated remediation should be introduced cautiously because storage incidents can be irreversible.

Best-Practice Checklist

A professional storage program should:

• maintain an authoritative inventory of devices, volumes, filesystems, owners, and dependencies;
• use stable identifiers and validate persistent mounts before rebooting;
• monitor bytes, inodes, latency, errors, RAID state, LVM metadata, and backup status;
• separate high-impact workloads where appropriate rather than allowing one filesystem to consume all capacity;
• document the layering and failure behavior of RAID, encryption, LVM, and filesystems;
• define RPO, RTO, retention, and restoration responsibilities with service owners;
• keep independent, encrypted, and preferably immutable backup copies;
• test restoration and disaster-recovery procedures on a scheduled basis;
• protect keys, credentials, and backup access as carefully as production systems; and
• review storage architecture whenever workload size, compliance requirements, or service criticality changes.

Chapter Summary

Linux storage administration spans a stack from block devices and partitions to filesystems, mounts, and applications. LVM provides flexible pooling and resizing, while RAID offers selected forms of hardware-failure tolerance. Persistent mounts, filesystem options, and swap require careful operational configuration. Network storage introduces shared access and new dependency failures, and object storage provides an API-oriented alternative for backups and unstructured data.

Capacity, performance, availability, and durability are distinct design objectives. Snapshots provide convenient point-in-time states but are not independent backups. Effective protection combines suitable backup copies, retention policies, encryption, isolation, recovery objectives, and tested restoration. Disaster recovery extends beyond technology to include dependencies, people, runbooks, governance, and exercises. The central professional principle is that recoverability must be demonstrated, not assumed.

Key Terms

Block device: A device that provides addressable storage blocks to the operating system.

Filesystem: A structure that organizes blocks into files, directories, metadata, and permissions.

Mount point: A directory through which a filesystem is made available in the Linux namespace.

UUID: A persistent identifier commonly used to refer to a filesystem or storage object.

Physical volume: An LVM-managed device or partition contributing storage to a volume group.

Volume group: An LVM pool from which logical volumes are allocated.

Logical volume: A virtual block device created within an LVM volume group.

RAID: A method of combining devices for redundancy, performance, or capacity management.

Degraded array: A RAID array operating after losing one or more required members.

Snapshot: A point-in-time storage representation, usually using copy-on-write techniques.

Swap: Disk-based space used to support virtual memory when physical memory is insufficient.

NFS: A network filesystem protocol commonly used to share directories between Linux systems.

iSCSI: A protocol that transports block-storage commands over IP networks.

RPO: Recovery Point Objective, the maximum acceptable amount of data loss measured in time.

RTO: Recovery Time Objective, the maximum acceptable time to restore a service.

Retention: The policy determining how long data and backups are preserved.

Immutability: A property preventing protected data from being altered or deleted during a defined period.

Disaster recovery: The coordinated process of restoring services after a major disruptive event.

Filesystem inode: Metadata structure representing a file and its attributes, distinct from file content blocks.

Review Questions

Short Answer Questions

1. Distinguish a block device, filesystem, and mount point.

2. Why are UUIDs generally preferred to `/dev/sdX` names in persistent mount configuration?

3. What is the difference between an LVM volume group and a logical volume?

4. Why is RAID not a substitute for backup?

5. Define RPO and RTO.

Long Answer Questions

1. Explain the Linux storage stack from physical media to application-visible files, including the role of partitions, RAID, LVM, filesystems, and mounts.

2. Describe a safe procedure for expanding an LVM-backed filesystem and explain why filesystem type matters.

3. Compare RAID 1, RAID 5, RAID 6, and RAID 10 in terms of redundancy, performance, and operational risk.

4. Design a backup and retention strategy for a database service with strict recovery requirements.

5. Explain how a disaster-recovery plan differs from a high-availability design and identify the components a DR runbook should contain.

Analytical / Application Questions

1. A server reports 40% free filesystem space, but an application cannot create new files. What evidence would you collect, and which storage conditions could explain the problem?

2. An organization stores daily snapshots on the same array as production and claims it has a reliable backup strategy. Evaluate the claim and propose a stronger design.

3. A company requires an RPO of fifteen minutes and an RTO of one hour across a regional failure. Develop a storage and recovery architecture, stating the trade-offs and tests needed to validate it.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the relationship between a filesystem and a mount point?

A. A filesystem is a directory, while a mount point is a physical disk.

B. A mount point is the directory through which a filesystem is exposed in the Linux namespace.

C. A filesystem is always created directly on a network interface.

D. A mount point stores a backup copy of the filesystem.

Correct Answer: B. A mount point is the directory through which a filesystem is exposed in the Linux namespace.

Question 2

An administrator wants a persistent mount that remains correct even if device enumeration changes after reboot. Which identifier is most appropriate?

A. /dev/sdb

B. The current process ID

C. The filesystem UUID

D. The system hostname

Correct Answer: C. The filesystem UUID

Question 3

What is a principal operational advantage of LVM?

A. It guarantees protection from ransomware.

B. It allows storage to be pooled and logical volumes to be managed flexibly.

C. It eliminates the need for filesystems.

D. It makes every filesystem automatically shared across hosts.

Correct Answer: B. It allows storage to be pooled and logical volumes to be managed flexibly.

Question 4

A RAID 1 array is best characterized as providing:

A. Striping without redundancy

B. Distributed parity with tolerance for two failures

C. Mirroring, with continued operation after a suitable member failure

D. A geographically independent backup copy

Correct Answer: C. Mirroring, with continued operation after a suitable member failure

Question 5

Why should a snapshot on the same storage array as production not be considered a complete backup strategy?

A. Snapshots cannot represent a point in time.

B. The snapshot may be lost if the array suffers a destructive failure.

C. Snapshots always consume more space than the source.

D. Snapshots cannot be used for restoration.

Correct Answer: B. The snapshot may be lost if the array suffers a destructive failure.

Question 6

A filesystem has substantial free space according to `df -h`, but creation of small files fails. Which additional check is most relevant?

A. The number of logged-in users

B. Inode utilization using `df -i`

C. The system hostname

D. The RAID level only

Correct Answer: B. Inode utilization using `df -i`

Question 7

Which statement correctly distinguishes RPO from RTO?

A. RPO measures restoration time; RTO measures permitted data loss.

B. RPO measures permitted data loss; RTO measures permitted restoration time.

C. Both measure storage capacity.

D. Both refer only to RAID rebuild duration.

Correct Answer: B. RPO measures permitted data loss; RTO measures permitted restoration time.

Question 8

A normal single-host filesystem is placed on an iSCSI block device. What is a critical concern before mounting it read-write on multiple hosts?

A. Whether the hosts have identical usernames

B. Whether the filesystem supports coordinated clustered access

C. Whether the device has a filesystem UUID

D. Whether swap is enabled

Correct Answer: B. Whether the filesystem supports coordinated clustered access

Question 9

Which practice provides the strongest evidence that backups are usable?

A. Checking that the backup job reports success

B. Confirming that backup storage is nearly full

C. Performing scheduled restoration tests and validating application data

D. Creating more snapshots on the production array

Correct Answer: C. Performing scheduled restoration tests and validating application data

Question 10

A company needs rapid rollback from accidental application changes but also protection from a site-wide storage failure. Which design is most appropriate?

A. Use only local snapshots.

B. Use only RAID 0.

C. Combine local snapshots with independent, geographically separated backups.

D. Disable monitoring to reduce storage overhead.

Correct Answer: C. Combine local snapshots with independent, geographically separated backups.