In this article, we’ll explain what NFS is, how exporting works from first principles, and walk through the complete process of configuring an NFS export on Linux, step by step, with troubleshooting and best practices.

Table of Contents

1. What Is NFS?
2. How Does NFS Work Under the Hood?
3. What Does “Exporting” a File System Mean?
4. Prerequisites
5. Step-by-Step: Installing NFS Server
6. Step-by-Step: Creating and Configuring the Export
7. Understanding the /etc/exports File Syntax
8. Applying and Verifying Exports
9. Firewall Configuration
10. NFS Versions Explained
11. Real-World Example
12. Cisco/Network Context
13. Python Example: Checking NFS Export Availability
14. Comparison Table: NFS Export Options
15. Best Practices
16. Troubleshooting Common Issues
17. Conclusion

1. What Is NFS?

NFS (Network File System) is a distributed file system protocol, originally developed by Sun Microsystems, that allows a computer (the NFS server) to share directories over a network so that other computers (NFS clients) can mount and access those directories as though they were part of their own local file system.

Unlike simply copying files between machines, NFS provides live, real-time access — when a file changes on the server, every client sees the change immediately, because they’re all reading from the same underlying storage.

2. How Does NFS Work Under the Hood?

NFS operates using a client-server model over the network, historically relying on RPC (Remote Procedure Call) to communicate between the client and server. When a client wants to read or write a file:

1. The client sends an RPC request to the NFS server, referencing the exported directory and the desired file operation (read, write, list, etc.).
2. The server checks whether the client is authorized to access that export (based on IP address, hostname, or network range).
3. The server performs the operation on the actual file system and sends the result back to the client.
4. The client’s operating system presents this remote directory to local applications exactly like a normal local folder.

sequenceDiagram
    participant Client as NFS Client
    participant Server as NFS Server
    participant Disk as Local Disk (Server)

    Client->>Server: Mount request for /shared
    Server->>Server: Check /etc/exports permissions
    Server->>Client: Mount granted
    Client->>Server: Read file request
    Server->>Disk: Fetch file data
    Disk->>Server: Return file data
    Server->>Client: File data returned

3. What Does “Exporting” a File System Mean?

Exporting is the process, performed on the NFS server, of declaring which local directories are available for remote clients to mount, and defining the rules for who can access them and what permissions they have (read-only, read-write, etc.). This is configured in a special file called /etc/exports.

Think of exporting as “publishing” a folder to the network with a specific access policy — similar to sharing a folder in Windows, but using the NFS protocol instead of SMB.

4. Prerequisites

Before exporting a file system with NFS, you need:

• A Linux server (Ubuntu, Debian, CentOS, RHEL, etc.) that will act as the NFS server.
• Root or sudo access on that server.
• A directory you want to share (e.g., /srv/nfs/shared).
• Basic knowledge of the client machines’ IP addresses or subnet that should be allowed access.
• An open network path between server and clients (typically port 2049 for NFS).

5. Step-by-Step: Installing NFS Server

On Ubuntu/Debian-based systems:

sudo apt update
sudo apt install nfs-kernel-server -y

sudo apt update
sudo apt install nfs-kernel-server -y

On CentOS/RHEL/Fedora-based systems:

sudo dnf install nfs-utils -y

sudo dnf install nfs-utils -y

Start and enable the NFS service so it runs on boot

sudo systemctl start nfs-server
sudo systemctl enable nfs-server
sudo systemctl status nfs-server

sudo systemctl start nfs-server
sudo systemctl enable nfs-server
sudo systemctl status nfs-server

6. Step-by-Step: Creating and Configuring the Export

Step 1: Create the directory you want to share.

sudo mkdir -p /srv/nfs/shared

sudo mkdir -p /srv/nfs/shared

Step 2: Set appropriate ownership and permissions.

sudo chown nobody:nogroup /srv/nfs/shared   # Ubuntu/Debian
sudo chown nobody:nobody /srv/nfs/shared    # CentOS/RHEL
sudo chmod 755 /srv/nfs/shared

sudo chown nobody:nogroup /srv/nfs/shared   # Ubuntu/Debian
sudo chown nobody:nobody /srv/nfs/shared    # CentOS/RHEL
sudo chmod 755 /srv/nfs/shared

Step 3: Edit the /etc/exports file to declare the export.

sudo nano /etc/exports

sudo nano /etc/exports

Add a line like this:

/srv/nfs/shared    192.168.1.0/24(rw,sync,no_subtree_check)

/srv/nfs/shared    192.168.1.0/24(rw,sync,no_subtree_check)

This line tells the NFS server: “Export the /srv/nfs/shared directory to any client on the 192.168.1.0/24 subnet, allow read-write access, use synchronous writes, and don’t check subtree permissions.”

7. Understanding the /etc/exports File Syntax

The general syntax of an entry in /etc/exports is:

<directory>   <client_specification>(<options>)

<directory>   <client_specification>(<options>)

Common client specifications:

Common export options:

8. Applying and Verifying Exports

Apply the changes without restarting the whole service:

sudo exportfs -ra

sudo exportfs -ra

View all currently active exports:

sudo exportfs -v

sudo exportfs -v

Sample output:

/srv/nfs/shared  192.168.1.0/24(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

/srv/nfs/shared  192.168.1.0/24(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

Verify the NFS server is listening on the correct port:

sudo ss -tulnp | grep nfs

sudo ss -tulnp | grep nfs

9. Firewall Configuration

NFS uses several ports, primarily 2049 (TCP/UDP), along with additional ports for related services like rpcbind and mountd.

On systems using firewalld (CentOS/RHEL):

sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --reload

sudo firewall-cmd --permanent --add-service=nfs
sudo firewall-cmd --permanent --add-service=rpc-bind
sudo firewall-cmd --permanent --add-service=mountd
sudo firewall-cmd --reload

On systems using ufw (Ubuntu/Debian):

sudo ufw allow from 192.168.1.0/24 to any port nfs

sudo ufw allow from 192.168.1.0/24 to any port nfs

10. NFS Versions Explained

Modern deployments should prefer NFSv4 for its simplified firewall requirements (single port) and improved security model.

11. Real-World Example

A university research lab has a central Linux server storing large genomic datasets. Instead of copying multi-gigabyte files to every researcher’s workstation, the lab administrator exports the dataset directory via NFS:

/data/genomics    10.10.20.0/24(ro,sync,no_subtree_check)

/data/genomics    10.10.20.0/24(ro,sync,no_subtree_check)

Every workstation on the 10.10.20.0/24 subnet can now mount /data/genomics as read-only, allowing dozens of researchers to analyze the same dataset simultaneously without duplicating storage.

Extended Example: Multi-Tier Access for a Media Production Team

A video production company stores raw footage, editing project files, and final rendered exports on a central Linux storage server. Different teams need different levels of access:

/srv/nfs/raw-footage      192.168.10.0/24(ro,sync,no_subtree_check)
/srv/nfs/editing-projects 192.168.10.0/24(rw,sync,no_subtree_check)
/srv/nfs/final-renders    192.168.10.50(rw,sync,no_subtree_check)

/srv/nfs/raw-footage      192.168.10.0/24(ro,sync,no_subtree_check)
/srv/nfs/editing-projects 192.168.10.0/24(rw,sync,no_subtree_check)
/srv/nfs/final-renders    192.168.10.50(rw,sync,no_subtree_check)

Here, the entire editing subnet has read-only access to raw footage (protecting original camera files from accidental modification), read-write access to active editing projects, and only the rendering workstation (192.168.10.50) has write access to the final renders directory — a practical illustration of how granular, per-directory export rules support real production workflows.

12. Cisco/Network Context

While Cisco switches and routers don’t run NFS themselves, they are responsible for ensuring the network path between NFS clients and the server is reliable, since NFS is sensitive to packet loss and latency (especially with sync writes). Network administrators should ensure:

QoS prioritization for NFS traffic on a Cisco switch (example, marking NFS traffic for priority handling):

Switch(config)# access-list 101 permit tcp any any eq 2049
Switch(config)# class-map match-all NFS-TRAFFIC
Switch(config-cmap)# match access-group 101
Switch(config-cmap)# exit
Switch(config)# policy-map QOS-POLICY
Switch(config-pmap)# class NFS-TRAFFIC
Switch(config-pmap-c)# priority percent 30

Switch(config)# access-list 101 permit tcp any any eq 2049
Switch(config)# class-map match-all NFS-TRAFFIC
Switch(config-cmap)# match access-group 101
Switch(config-cmap)# exit
Switch(config)# policy-map QOS-POLICY
Switch(config-pmap)# class NFS-TRAFFIC
Switch(config-pmap-c)# priority percent 30

This ensures NFS traffic (port 2049) receives prioritized bandwidth on a congested network, which is especially important in environments like the CAN/MAN networks discussed in earlier articles.

13. Python Example: Checking NFS Export Availability

The following Python script uses a simple socket check to verify whether the NFS port (2049) is open and reachable on the server before a client attempts to mount it — a handy pre-flight check.

import socket

def check_nfs_port(server_ip, port=2049, timeout=3):
    try:
        with socket.create_connection((server_ip, port), timeout=timeout):
            return True
    except (socket.timeout, ConnectionRefusedError, OSError):
        return False

server_ip = "192.168.1.100"

if check_nfs_port(server_ip):
    print(f"NFS server at {server_ip} is reachable on port 2049.")
else:
    print(f"NFS server at {server_ip} is NOT reachable on port 2049. Check firewall/service status.")

import socket

def check_nfs_port(server_ip, port=2049, timeout=3):
    try:
        with socket.create_connection((server_ip, port), timeout=timeout):
            return True
    except (socket.timeout, ConnectionRefusedError, OSError):
        return False

server_ip = "192.168.1.100"

if check_nfs_port(server_ip):
    print(f"NFS server at {server_ip} is reachable on port 2049.")
else:
    print(f"NFS server at {server_ip} is NOT reachable on port 2049. Check firewall/service status.")

Sample Output:

NFS server at 192.168.1.100 is reachable on port 2049.

NFS server at 192.168.1.100 is reachable on port 2049.

14. Comparison Table: NFS Export Options

15. Best Practices

• Always restrict exports to specific subnets or IPs — never use * in production environments.
• Prefer root_squash unless you have a specific, well-understood reason to disable it.
• Use NFSv4 where possible for simplified firewall rules and better security (Kerberos support).
• Combine NFS with proper firewall rules, restricting access to only the necessary client subnet.
• Regularly back up /etc/exports and version-control it if managing multiple NFS servers.
• Monitor NFS server load using tools like nfsstat to catch performance bottlenecks early.

16. Troubleshooting Common Issues

Quick diagnostic commands:

sudo exportfs -v                  # List all current exports
sudo systemctl status nfs-server  # Check NFS service status
rpcinfo -p localhost              # Check registered RPC services (NFSv3)
showmount -e localhost            # Show exports as seen locally

sudo exportfs -v                  # List all current exports
sudo systemctl status nfs-server  # Check NFS service status
rpcinfo -p localhost              # Check registered RPC services (NFSv3)
showmount -e localhost            # Show exports as seen locally

17. Advanced Concepts: NFS Security Hardening

Beyond basic export configuration, production NFS deployments benefit from additional security layers that go further than the default root_squash and subnet restrictions covered earlier.

Using Kerberos with NFSv4 (sec=krb5)

By default, NFS authenticates clients purely based on their IP address (sec=sys), which offers no real user-level authentication or encryption — anyone who can spoof or gain access to a trusted IP can potentially access the export. NFSv4 with Kerberos (sec=krb5, sec=krb5i for integrity checking, or sec=krb5p for full encryption) adds proper cryptographic authentication of individual users, not just client machines.

Example export line using Kerberos-based security:

/srv/nfs/secure    192.168.1.0/24(rw,sec=krb5p,no_subtree_check)

/srv/nfs/secure    192.168.1.0/24(rw,sec=krb5p,no_subtree_check)

This configuration requires clients to authenticate via a Kerberos ticket and encrypts all NFS traffic (krb5p), providing both authentication and confidentiality — a significant security upgrade over the default IP-based trust model.

Restricting Exports with TCP Wrappers and Firewalls

In addition to the access rules defined directly in /etc/exports, administrators should layer host-based firewall rules (via iptables, nftables, or firewalld) to ensure that even if /etc/exports is ever misconfigured, unauthorized networks cannot reach the NFS ports at all. Defense in depth — combining application-level (/etc/exports) and network-level (firewall) restrictions — is a core security best practice.

Read-Only Root Exports for Immutable Data

For directories containing reference data, installation media, or compliance archives that should never change, exporting with ro (read-only) at the NFS level, combined with filesystem-level immutability (chattr +i on Linux), provides two independent layers of protection against accidental or malicious modification.

18. NFS vs. Other File Sharing Protocols

It’s useful to understand how NFS compares to alternative file-sharing protocols, since the right choice depends heavily on your operating system mix and use case.

NFS remains the preferred choice in Linux-heavy environments — data centers, research clusters, and container storage backends — due to its maturity, performance, and tight integration with Unix-style permissions.

19. Monitoring and Auditing NFS Exports Over Time

Once an NFS export is live in production, ongoing monitoring is essential to catch performance degradation, unauthorized access attempts, or configuration drift before they become serious problems.

Monitor active NFS connections and operation counts:

sudo nfsstat -s

sudo nfsstat -s

This command displays server-side statistics, including counts of read/write calls, and can help identify unusually high load from a specific client subnet.

Audit who is currently connected to your NFS exports:

sudo ss -tn | grep :2049

sudo ss -tn | grep :2049

Log NFS mount and unmount events for auditing purposes by enabling verbose logging in rpc.mountd (part of the nfs-utils package), which records every client that mounts an export, along with the timestamp — valuable for security audits in regulated environments.

Periodically review /etc/exports for drift:

Configuration drift — where the live export rules on a server slowly diverge from documented policy due to ad-hoc changes — is a common issue in long-running infrastructure. Storing /etc/exports in a version-controlled configuration management system (Ansible, Puppet, or even a simple Git repository) ensures every change is tracked, reviewed, and reversible.

20. Frequently Asked Questions

Can I export the same directory to different clients with different permissions?

Yes. You can add multiple lines in /etc/exports for the same directory, each specifying a different client or subnet with its own options. For example, you might grant rw access to your internal admin subnet while granting only ro access to a broader internal network.

/srv/nfs/shared    192.168.1.0/24(ro,sync,no_subtree_check)
/srv/nfs/shared    192.168.1.50(rw,sync,no_subtree_check)

/srv/nfs/shared    192.168.1.0/24(ro,sync,no_subtree_check)
/srv/nfs/shared    192.168.1.50(rw,sync,no_subtree_check)

What happens if the NFS server goes offline while clients have it mounted?

Depending on the mount options used, client applications accessing the share may hang indefinitely (hard mount, the default) until the server returns, or fail immediately with an I/O error (soft mount). For most production use cases, hard mounts are preferred despite the temporary hang, because soft mounts risk silent data corruption if a write operation is interrupted mid-transfer.

Is NFS suitable for storing a live database’s data files?

Generally, no. Databases like MySQL or PostgreSQL typically expect strict, immediate file-locking guarantees that NFS — especially older versions or misconfigured setups — may not reliably provide, risking data corruption. Most database vendors explicitly recommend local or block-level storage (like iSCSI) over NFS for primary database files, reserving NFS for backups, logs, or shared application data instead.

How many clients can mount the same NFS export simultaneously?

There’s no hard protocol-level limit built into NFS itself; the practical ceiling depends on the server’s CPU, memory, disk I/O throughput, and network bandwidth. Large-scale deployments in research and enterprise environments routinely support hundreds of simultaneous client connections to a single, well-provisioned NFS server, often backed by high-performance storage arrays and 10 Gbps or faster network links.

21. Conclusion

Exporting a file system with NFS in Linux is a foundational, practical skill for anyone managing shared storage in a networked environment. By installing the NFS server package, defining directories and access rules in /etc/exports, applying the export with exportfs -ra, and properly configuring your firewall, you can securely share files across your network — whether that’s a small home lab or a university research cluster. In the next article, we’ll cover the client side of this process: how to actually mount and use these NFS exports from remote machines.

Whether you’re setting up a small home lab for shared media storage or architecting a multi-terabyte research data platform for a university department, the same core principles apply: carefully scope your export’s client access, choose sensible read/write and squash options, validate your configuration before restarting services, and layer network-level firewall rules on top of the application-level rules defined in /etc/exports. Mastering the export side of NFS is the foundation upon which all remote file access is built. Once you’re comfortable defining directories, access rules, and security options in /etc/exports, the natural next step — covered in depth in the following article — is understanding how client machines discover, mount, and interact with these exports in day-to-day use, completing the full picture of NFS-based file sharing across a network.

Further Reading

• Linux exports Man Page
• Red Hat — Configuring an NFS Server
• Ubuntu Server Documentation — NFS
• IETF RFC 8881 — NFSv4.1 Protocol Specification
• Cisco QoS Configuration Guide
• Linux firewalld Documentation
• MIT Kerberos Documentation — Securing NFSv4 with Strong Authentication
• Arch Linux Wiki — NFS/Troubleshooting

The post How to Export a File System with NFS in Linux appeared first on Abdul Wahab Junaid.

Table of Contents

1. Recap: What Is NFS File Sharing?
2. The Complete NFS Sharing Workflow
3. Server-Side Quick Setup
4. Client-Side: Installing NFS Utilities
5. Manually Mounting an NFS Share
6. Making the Mount Persistent with /etc/fstab
7. Auto-Mounting with autofs
8. Verifying and Testing File Sharing
9. Permissions and User Mapping Challenges
10. Real-World Example: Shared Team Directory
11. Cisco/Network Considerations for Multi-Site Sharing
12. Python Example: Automating Mount Verification
13. Comparison Table: Mounting Methods
14. Best Practices
15. Troubleshooting Common Issues
16. Conclusion

1. Recap: What Is NFS File Sharing?

NFS (Network File System) allows one Linux machine (the server) to make a directory available over the network, and other machines (clients) to mount that directory into their own file system tree. Once mounted, users on the client machine can read, write, create, and delete files in that shared directory exactly as if it were a local folder — all changes are instantly reflected for every other client with the same directory mounted.

2. The Complete NFS Sharing Workflow

graph LR
    A[1. Server: Install nfs-kernel-server] --> B[2. Server: Create shared directory]
    B --> C[3. Server: Add entry to /etc/exports]
    C --> D[4. Server: Run exportfs -ra]
    D --> E[5. Client: Install nfs-common]
    E --> F[6. Client: Create mount point directory]
    F --> G[7. Client: Mount the NFS share]
    G --> H[8. Users on client read/write files]

This diagram represents the complete end-to-end process — from setting up the server export (covered in the previous article) through to actually mounting and using the share on a client machine, which is our focus here.

3. Server-Side Quick Setup

For completeness, here’s a condensed version of the server-side steps (covered in detail in the previous article):

sudo apt update
sudo apt install nfs-kernel-server -y
sudo mkdir -p /srv/nfs/teamshare
sudo chown nobody:nogroup /srv/nfs/teamshare
sudo chmod 2775 /srv/nfs/teamshare
echo "/srv/nfs/teamshare  192.168.1.0/24(rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
sudo exportfs -ra
sudo systemctl enable --now nfs-server

sudo apt update
sudo apt install nfs-kernel-server -y
sudo mkdir -p /srv/nfs/teamshare
sudo chown nobody:nogroup /srv/nfs/teamshare
sudo chmod 2775 /srv/nfs/teamshare
echo "/srv/nfs/teamshare  192.168.1.0/24(rw,sync,no_subtree_check)" | sudo tee -a /etc/exports
sudo exportfs -ra
sudo systemctl enable --now nfs-server

4. Client-Side: Installing NFS Utilities

On the client machine, you need the NFS client package, which is separate from the server package.

On Ubuntu/Debian:

sudo apt update
sudo apt install nfs-common -y

sudo apt update
sudo apt install nfs-common -y

On CentOS/RHEL/Fedora:

sudo dnf install nfs-utils -y

sudo dnf install nfs-utils -y

5. Manually Mounting an NFS Share

Step 1: Create a local mount point (an empty directory that will act as the access point).

sudo mkdir -p /mnt/teamshare

sudo mkdir -p /mnt/teamshare

Step 2: Mount the remote NFS export.

sudo mount -t nfs 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

sudo mount -t nfs 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

Here, 192.168.1.100 is the NFS server’s IP address, /srv/nfs/teamshare is the exported directory on the server, and /mnt/teamshare is the local mount point on the client.

Step 3: Verify the mount was successful.

df -h | grep teamshare

df -h | grep teamshare

Sample output:

192.168.1.100:/srv/nfs/teamshare   50G   12G   38G   24%  /mnt/teamshare

192.168.1.100:/srv/nfs/teamshare   50G   12G   38G   24%  /mnt/teamshare

Step 4: Test file sharing by creating a file.

echo "Hello from client!" > /mnt/teamshare/test.txt
cat /mnt/teamshare/test.txt

echo "Hello from client!" > /mnt/teamshare/test.txt
cat /mnt/teamshare/test.txt

If another client also has this same share mounted, they will immediately see test.txt appear in their /mnt/teamshare directory too.

6. Making the Mount Persistent with /etc/fstab

A manual mount using the mount command will disappear after a reboot. To make it persistent, add an entry to /etc/fstab.

Edit the fstab file:

sudo nano /etc/fstab

sudo nano /etc/fstab

Add this line:

192.168.1.100:/srv/nfs/teamshare   /mnt/teamshare   nfs   defaults,_netdev   0   0

192.168.1.100:/srv/nfs/teamshare   /mnt/teamshare   nfs   defaults,_netdev   0   0

The _netdev option is important — it tells the system to wait until the network is up before attempting to mount, preventing boot failures.

Test the fstab entry without rebooting:

sudo mount -a

sudo mount -a

7. Auto-Mounting with autofs

For environments where you don’t want the NFS share mounted permanently (to save resources or avoid boot delays if the server is temporarily unreachable), autofs mounts the share on-demand when accessed, and automatically unmounts it after a period of inactivity.

Install autofs:

sudo apt install autofs -y

sudo apt install autofs -y

Configure the master map file:

echo "/mnt/auto  /etc/auto.nfs" | sudo tee -a /etc/auto.master

echo "/mnt/auto  /etc/auto.nfs" | sudo tee -a /etc/auto.master

Create the map file /etc/auto.nfs:

teamshare    -rw,sync    192.168.1.100:/srv/nfs/teamshare

teamshare    -rw,sync    192.168.1.100:/srv/nfs/teamshare

Restart autofs:

sudo systemctl restart autofs

sudo systemctl restart autofs

Now, accessing /mnt/auto/teamshare for the first time will automatically trigger the mount, and it will unmount itself after being idle.

8. Verifying and Testing File Sharing

Check active NFS mounts on a client:

mount | grep nfs

mount | grep nfs

View NFS statistics (read/write operations, retransmissions):

nfsstat -c

nfsstat -c

Check what a server is exporting from the client side, before mounting:

showmount -e 192.168.1.100

showmount -e 192.168.1.100

Sample output:

Export list for 192.168.1.100:
/srv/nfs/teamshare 192.168.1.0/24

Export list for 192.168.1.100:
/srv/nfs/teamshare 192.168.1.0/24

9. Permissions and User Mapping Challenges

One of the trickiest parts of NFS file sharing is that user and group IDs (UID/GID) are shared by number, not by name, across client and server. If a user “alice” has UID 1001 on the server but UID 1005 on the client, file ownership will appear incorrect or inaccessible on one side.

Best solutions to this problem:

• Use a centralized identity system like LDAP or FreeIPA so UIDs/GIDs are consistent across all machines.
• Use NFSv4 with idmapping (/etc/idmapd.conf), which maps users by name rather than raw UID number, provided both server and client have matching domain settings.
• Manually align UIDs/GIDs when creating users on server and client machines in smaller environments.

Example /etc/idmapd.conf domain setting (must match on server and client):

[General]
Domain = example.com

[General]
Domain = example.com

10. Real-World Example: Shared Team Directory

A small software development team has five developers working from five different Linux workstations. Instead of using Git alone for everything (some large binary assets aren’t well-suited to version control), the team sets up a shared NFS directory for design assets:

• Server: fileserver.internal exports /srv/nfs/design-assets with rw access to the 192.168.1.0/24 subnet.
• Clients: Each developer’s workstation mounts this at /mnt/design-assets via /etc/fstab.
• Result: Any designer or developer can drop a new asset into the shared folder, and it’s instantly visible and editable by the rest of the team — no manual file transfers, no version conflicts on binary assets.

graph TD
    S[File Server: /srv/nfs/design-assets] --> C1[Developer 1: /mnt/design-assets]
    S --> C2[Developer 2: /mnt/design-assets]
    S --> C3[Developer 3: /mnt/design-assets]
    S --> C4[Developer 4: /mnt/design-assets]

11. Cisco/Network Considerations for Multi-Site Sharing

If clients and the NFS server are on different sites connected via a WAN (as discussed in our LAN/MAN/WAN article), NFS performance can degrade significantly due to latency, since NFS was originally designed for fast local networks. Considerations include:

• Avoid NFS over high-latency WAN links for interactive workloads; consider a caching file system or a sync tool (like rsync) instead.
• If NFS over WAN is unavoidable, use NFSv4.1+ with features like pNFS and increase read/write buffer sizes (rsize/wsize mount options) to reduce round trips.
• Configure QoS on Cisco routers/switches to prioritize NFS traffic (port 2049) across the WAN link, similar to the example shown in the previous article.

Example: increasing NFS buffer sizes on a slower link:

sudo mount -t nfs -o rsize=32768,wsize=32768,timeo=30 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

sudo mount -t nfs -o rsize=32768,wsize=32768,timeo=30 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

12. Python Example: Automating Mount Verification

This Python script checks whether a list of expected NFS mounts are actually active on a client machine — useful for automated health checks across a fleet of workstations.

import subprocess

expected_mounts = ["/mnt/teamshare", "/mnt/design-assets"]

def get_active_nfs_mounts():
    result = subprocess.run(["mount", "-t", "nfs,nfs4"], capture_output=True, text=True)
    return result.stdout

active_output = get_active_nfs_mounts()

for mount_point in expected_mounts:
    if mount_point in active_output:
        print(f"[OK]      {mount_point} is mounted.")
    else:
        print(f"[MISSING] {mount_point} is NOT mounted!")

import subprocess

expected_mounts = ["/mnt/teamshare", "/mnt/design-assets"]

def get_active_nfs_mounts():
    result = subprocess.run(["mount", "-t", "nfs,nfs4"], capture_output=True, text=True)
    return result.stdout

active_output = get_active_nfs_mounts()

for mount_point in expected_mounts:
    if mount_point in active_output:
        print(f"[OK]      {mount_point} is mounted.")
    else:
        print(f"[MISSING] {mount_point} is NOT mounted!")

Sample Output:

[OK]      /mnt/teamshare is mounted.
[MISSING] /mnt/design-assets is NOT mounted!

[OK]      /mnt/teamshare is mounted.
[MISSING] /mnt/design-assets is NOT mounted!

This kind of script can be scheduled with cron to alert administrators when an expected NFS mount has silently failed or been unmounted.

13. Comparison Table: Mounting Methods

14. Best Practices

• Always test mounts manually before adding them to /etc/fstab to avoid boot failures from typos.
• Use the _netdev option in /etc/fstab for any NFS mount to prevent boot delays or failures when the network isn’t ready yet.
• Standardize UID/GID mapping across your organization using LDAP, FreeIPA, or NFSv4 idmapping to avoid permission headaches.
• Use autofs for laptops or intermittently connected clients to avoid hanging boot processes when the NFS server is unreachable.
• Monitor NFS mounts with automated health checks (like the Python script above) to catch silent failures early.
• Avoid NFS for latency-sensitive workloads over WAN links; prefer it for LAN/CAN environments where it performs best.

15. Troubleshooting Common Issues

Quick fix for a stale NFS mount:

sudo umount -f /mnt/teamshare
sudo mount -a

sudo umount -f /mnt/teamshare
sudo mount -a

16. Advanced Concepts: NFS Locking and Concurrent Access

One of the trickiest aspects of sharing files with NFS is understanding how the protocol handles file locking when multiple clients attempt to read or write the same file simultaneously.

Network Lock Manager (NLM) in NFSv3

NFSv3 relies on a separate protocol called NLM (Network Lock Manager), running alongside NFS itself, to coordinate file locks between clients. This historically caused issues, since NLM state could be lost if the server rebooted, requiring clients to detect the failure and re-acquire locks — a process that isn’t always seamless.

Integrated Locking in NFSv4

NFSv4 solves this by integrating locking directly into the core protocol (no separate NLM service required), and by introducing the concept of a lease — a time-bounded grant of access that a client must periodically renew. If a client fails to renew its lease (for example, due to a crash or network partition), the server automatically releases the lock, preventing indefinite blocking of other clients.

sequenceDiagram
    participant C1 as Client 1
    participant Server as NFSv4 Server
    participant C2 as Client 2

    C1->>Server: Request lock on file.txt
    Server->>C1: Lock granted (lease started)
    C2->>Server: Request lock on file.txt
    Server->>C2: Lock denied - already held
    C1->>Server: Release lock / lease expires
    Server->>C2: Lock now available
    C2->>Server: Request lock on file.txt
    Server->>C2: Lock granted

Practical Implications for Shared Teams

When multiple users on different client machines are actively editing files in a shared NFS directory, application-level locking behavior matters as much as NFS’s own lock handling. Text editors and office applications that respect flock()/fcntl() locking will correctly prevent simultaneous conflicting writes, while poorly behaved applications that ignore locks entirely can still cause silent overwrites regardless of what NFS itself supports. This is why many teams pair NFS shared storage with version control (for code) or dedicated collaborative editing tools (for documents), rather than relying solely on file-level locking for critical concurrent work.

17. NFS Performance Tuning Tips

Beyond correct configuration, several tuning options can meaningfully improve NFS performance in demanding environments:

Example mount command combining several performance tuning options:

sudo mount -t nfs4 -o rsize=131072,wsize=131072,noatime,nconnect=4 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

sudo mount -t nfs4 -o rsize=131072,wsize=131072,noatime,nconnect=4 192.168.1.100:/srv/nfs/teamshare /mnt/teamshare

18. Frequently Asked Questions

Can Windows machines mount a Linux NFS export?

Yes, though it requires enabling the “NFS Client” feature on Windows (available in Windows 10/11 Pro and Enterprise editions, and Windows Server), or using third-party NFS client software. That said, in mixed Windows/Linux environments, many organizations prefer SMB/CIFS for Windows clients and reserve NFS specifically for Linux-to-Linux sharing, to avoid UID/GID mapping complications between the two very different permission models.

What happens if two clients edit the same file at the exact same time?

Without proper application-level locking, the last write to complete typically “wins,” silently overwriting the other client’s changes — a classic race condition. This is why collaborative editing of the same file by multiple simultaneous users is generally discouraged over plain NFS shares unless the applications involved implement robust locking or conflict resolution themselves.

Is it safe to run NFS shares over an untrusted public network?

Not without additional protection. Traditional NFS (sec=sys) trusts client IP addresses without strong authentication or encryption, making it unsuitable for use directly over the public internet. If NFS access is genuinely needed across untrusted networks, tunnel it through a VPN or use NFSv4 with Kerberos-based security (sec=krb5p) as covered in the previous article, rather than exposing NFS ports directly to the internet.

19. Scaling NFS Sharing Beyond a Single Server

As an organization grows, a single NFS server eventually becomes a bottleneck or a single point of failure. Several architectural approaches address this at scale:

• NFS with High Availability (HA) clustering: Tools like Pacemaker and Corosync on Linux allow two or more servers to share a virtual IP address and storage backend, so if the primary NFS server fails, a standby server takes over transparently, and clients experience only a brief pause rather than a full outage.
• Distributed file systems as an NFS alternative: For very large-scale deployments, systems like GlusterFS, CephFS, or Amazon EFS (in cloud environments) provide NFS-compatible interfaces backed by distributed, redundant storage across many physical nodes, rather than a single server.
• Read replicas for read-heavy workloads: In scenarios where most clients only need read access (like the raw footage example from the previous article), replicating data to multiple read-only NFS servers and distributing clients across them using DNS round-robin or a load balancer can significantly reduce load on any single machine.

graph TD
    VIP[Virtual IP: nfs.internal.company.local] --> Active[Active NFS Server]
    VIP -.->|Failover| Standby[Standby NFS Server]
    Active --- SharedStorage[(Shared/Replicated Storage)]
    Standby --- SharedStorage

20. Conclusion

Sharing files with NFS in Linux is a two-sided process: the server exports a directory with defined access rules, and clients mount that export locally, either manually, persistently via /etc/fstab, or on-demand via autofs. Once mounted, NFS creates a seamless, shared file system experience across multiple machines — ideal for team collaboration, centralized storage, and shared datasets within a LAN or CAN environment. Understanding UID/GID mapping and choosing the right mount strategy for your use case are the keys to a reliable, trouble-free NFS deployment.

Further Reading

• Linux mount Man Page
• Linux nfs Man Page
• Red Hat — Mounting NFS Shares
• Ubuntu Server Documentation — NFS Client Configuration
• Linux autofs Documentation
• IETF RFC 8881 — NFSv4.1 Protocol Specification

The post How to Share Files with NFS in Linux appeared first on Abdul Wahab Junaid.

Manual backups fail because humans forget, get busy, or simply assume “someone else is handling it.” Automated backups remove human memory from the equation entirely — the system backs itself up on a schedule, without anyone needing to remember to do it.

This article covers how to design and implement automated backup systems on Linux from first principles: what to back up, where to store it, how to schedule it, and how to verify it’s actually working — because a backup you’ve never tested is really just a hope, not a backup.

Why Automated (Not Manual) Backups?

The 3-2-1 Backup Rule

Before any technical implementation, it’s worth understanding the industry-standard guiding principle for backup strategy:

• 3 copies of your data (the original plus two backups)
• 2 different storage media types (e.g., local disk + cloud, or disk + tape)
• 1 copy stored offsite (so a fire, flood, or theft doesn’t destroy everything at once)

flowchart TD
    A[Production Data] --> B[Local Backup Copy]
    A --> C[Offsite/Cloud Backup Copy]
    B -.->|Different Media Type| D[e.g. External Disk]
    C -.->|Different Location| E[e.g. Cloud Storage / Remote Site]

Step 1: Decide What to Back Up

Not everything on a server needs backing up. Focus on:

• Configuration files (/etc/)
• Application data (databases, uploaded files, application state)
• User data (/home/)
• Web content (/var/www/)
• Databases (dumped in proper format, not just copied as raw files while running)

You generally do not need to back up:

• Operating system binaries (easily reinstalled)
• Temporary files (/tmp/)
• Cache directories
• Log files (unless required for compliance/auditing)

Step 2: Choose a Backup Tool

rsync — The Workhorse of Linux Backups

rsync efficiently copies only the parts of files that have changed, making it fast even for large datasets on repeat runs.

rsync -avz --delete /var/www/ /backup/www/

rsync -avz --delete /var/www/ /backup/www/

tar — Simple Archive Creation

tar -czvf /backup/website-backup-$(date +%F).tar.gz /var/www/

tar -czvf /backup/website-backup-$(date +%F).tar.gz /var/www/

rclone — For Cloud Storage Backups

rclone sync /var/www/ remote:my-backup-bucket/www/

rclone sync /var/www/ remote:my-backup-bucket/www/

rclone supports dozens of cloud providers (AWS S3, Google Drive, Backblaze B2, and more) with the same simple syntax.

Step 3: Automate with cron

cron is the classic Linux job scheduler — perfect for running backup scripts on a recurring schedule without any manual intervention.

Writing a Backup Script

sudo nano /usr/local/bin/backup.sh

sudo nano /usr/local/bin/backup.sh

#!/bin/bash
# Simple automated backup script

BACKUP_DIR="/backup"
SOURCE_DIR="/var/www"
DATE=$(date +%F)
LOGFILE="/var/log/backup.log"

echo "[$(date)] Starting backup..." >> "$LOGFILE"

mkdir -p "$BACKUP_DIR"

tar -czf "$BACKUP_DIR/backup-$DATE.tar.gz" "$SOURCE_DIR"

if [ $? -eq 0 ]; then
    echo "[$(date)] Backup completed successfully: backup-$DATE.tar.gz" >> "$LOGFILE"
else
    echo "[$(date)] BACKUP FAILED!" >> "$LOGFILE"
fi

# Remove backups older than 14 days
find "$BACKUP_DIR" -name "backup-*.tar.gz" -mtime +14 -delete

#!/bin/bash
# Simple automated backup script

BACKUP_DIR="/backup"
SOURCE_DIR="/var/www"
DATE=$(date +%F)
LOGFILE="/var/log/backup.log"

echo "[$(date)] Starting backup..." >> "$LOGFILE"

mkdir -p "$BACKUP_DIR"

tar -czf "$BACKUP_DIR/backup-$DATE.tar.gz" "$SOURCE_DIR"

if [ $? -eq 0 ]; then
    echo "[$(date)] Backup completed successfully: backup-$DATE.tar.gz" >> "$LOGFILE"
else
    echo "[$(date)] BACKUP FAILED!" >> "$LOGFILE"
fi

# Remove backups older than 14 days
find "$BACKUP_DIR" -name "backup-*.tar.gz" -mtime +14 -delete

Make it executable:

sudo chmod +x /usr/local/bin/backup.sh

sudo chmod +x /usr/local/bin/backup.sh

Scheduling with Cron

sudo crontab -e

sudo crontab -e

Add a line to run the backup every night at 2:00 AM:

0 2 * * * /usr/local/bin/backup.sh

0 2 * * * /usr/local/bin/backup.sh

Understanding Cron Syntax

* * * * *  command
│ │ │ │ │
│ │ │ │ └── Day of week (0-6, Sunday=0)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

* * * * *  command
│ │ │ │ │
│ │ │ │ └── Day of week (0-6, Sunday=0)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

Step 4: Automate Database Backups

Databases need special handling — copying raw database files while the database is running can produce corrupted, unusable backups. Always use the proper dump tool.

MySQL/MariaDB

mysqldump -u root -p'password' --all-databases | gzip > /backup/db-$(date +%F).sql.gz

mysqldump -u root -p'password' --all-databases | gzip > /backup/db-$(date +%F).sql.gz

PostgreSQL

pg_dumpall -U postgres | gzip > /backup/pgdb-$(date +%F).sql.gz

pg_dumpall -U postgres | gzip > /backup/pgdb-$(date +%F).sql.gz

Step 5: Send Backups Offsite

A local-only backup doesn’t protect against site-wide disasters (fire, theft, ransomware encrypting everything it can reach, including local backups!).

Using rsync to a Remote Server

rsync -avz -e ssh /backup/ user@remote-backup-server:/backups/server1/

rsync -avz -e ssh /backup/ user@remote-backup-server:/backups/server1/

Using rclone to Cloud Storage

rclone copy /backup/ remote:company-backups/server1/

rclone copy /backup/ remote:company-backups/server1/

Architecture Diagram: A Complete Automated Backup Flow

flowchart LR
    A[Cron Trigger 2 AM Daily] --> B[Backup Script Runs]
    B --> C[Dump Databases]
    B --> D[Archive Files with tar]
    C --> E[Local Backup Storage]
    D --> E
    E --> F[Sync Offsite via rsync/rclone]
    E --> G[Rotate: Delete Backups Older Than 14 Days]
    B --> H[Write Log Entry]
    H --> I[Alert on Failure via Email/Monitoring]

Real-World Example: E-Commerce Website Backup Strategy

A small online store running on a single Linux VPS might implement this layered strategy:

This layered approach means: if a bad deployment corrupts data at 3 PM, the store can restore from a 6-hour-old database snapshot rather than losing an entire day (or week) of orders.

Cisco Example: Backing Up Network Device Configurations

Automated backups aren’t just for servers — network device configurations should be backed up too. Cisco devices support automatic configuration backup via TFTP/SCP triggered from a script:

copy running-config tftp://192.168.1.100/backups/router1-config.txt

copy running-config tftp://192.168.1.100/backups/router1-config.txt

This can be automated from a Linux server using a scheduled script that connects via SSH and issues backup commands to multiple devices in sequence — often built with tools like Python’s netmiko library or Ansible.

Python Example: A More Robust Backup Script

import subprocess
import datetime
import os
import logging

logging.basicConfig(filename='/var/log/backup.log', level=logging.INFO,
                     format='%(asctime)s %(message)s')

BACKUP_DIR = "/backup"
SOURCE_DIR = "/var/www"
RETENTION_DAYS = 14

def run_backup():
    os.makedirs(BACKUP_DIR, exist_ok=True)
    date_str = datetime.date.today().isoformat()
    archive_path = f"{BACKUP_DIR}/backup-{date_str}.tar.gz"

    try:
        subprocess.run(
            ["tar", "-czf", archive_path, SOURCE_DIR],
            check=True
        )
        logging.info(f"Backup succeeded: {archive_path}")
    except subprocess.CalledProcessError as e:
        logging.error(f"Backup FAILED: {e}")
        return

    cleanup_old_backups()

def cleanup_old_backups():
    cutoff = datetime.datetime.now().timestamp() - (RETENTION_DAYS * 86400)
    for filename in os.listdir(BACKUP_DIR):
        filepath = os.path.join(BACKUP_DIR, filename)
        if os.path.getmtime(filepath) < cutoff:
            os.remove(filepath)
            logging.info(f"Removed old backup: {filename}")

if __name__ == "__main__":
    run_backup()

import subprocess
import datetime
import os
import logging

logging.basicConfig(filename='/var/log/backup.log', level=logging.INFO,
                     format='%(asctime)s %(message)s')

BACKUP_DIR = "/backup"
SOURCE_DIR = "/var/www"
RETENTION_DAYS = 14

def run_backup():
    os.makedirs(BACKUP_DIR, exist_ok=True)
    date_str = datetime.date.today().isoformat()
    archive_path = f"{BACKUP_DIR}/backup-{date_str}.tar.gz"

    try:
        subprocess.run(
            ["tar", "-czf", archive_path, SOURCE_DIR],
            check=True
        )
        logging.info(f"Backup succeeded: {archive_path}")
    except subprocess.CalledProcessError as e:
        logging.error(f"Backup FAILED: {e}")
        return

    cleanup_old_backups()

def cleanup_old_backups():
    cutoff = datetime.datetime.now().timestamp() - (RETENTION_DAYS * 86400)
    for filename in os.listdir(BACKUP_DIR):
        filepath = os.path.join(BACKUP_DIR, filename)
        if os.path.getmtime(filepath) < cutoff:
            os.remove(filepath)
            logging.info(f"Removed old backup: {filename}")

if __name__ == "__main__":
    run_backup()

Schedule this with cron just like the Bash version:

0 2 * * * /usr/bin/python3 /usr/local/bin/backup.py

0 2 * * * /usr/bin/python3 /usr/local/bin/backup.py

Comparison Table: Backup Tool Options

Best Practices

• Follow the 3-2-1 rule — multiple copies, multiple media types, at least one offsite.
• Automate everything — never rely on a human remembering to run a backup.
• Test restores regularly — a backup that’s never been restored is unverified and untrustworthy.
• Log every backup run, and alert on failures — a silent failure is worse than an obvious one.
• Encrypt backups, especially offsite/cloud copies, to protect sensitive data.
• Rotate old backups to avoid unbounded storage growth.
• Dump databases properly — never just copy live database files directly.
• Document your backup and restore procedures so anyone on the team can execute a recovery, not just the person who built it.

Troubleshooting

Useful Diagnostic Commands

# View recent cron job logs
grep CRON /var/log/syslog

# Manually test a backup script
sudo /usr/local/bin/backup.sh

# Verify archive integrity
tar -tzf /backup/backup-2026-07-24.tar.gz > /dev/null && echo "Archive OK"

# View recent cron job logs
grep CRON /var/log/syslog

# Manually test a backup script
sudo /usr/local/bin/backup.sh

# Verify archive integrity
tar -tzf /backup/backup-2026-07-24.tar.gz > /dev/null && echo "Archive OK"

Summary

Automated backups turn data protection from a fragile, human-dependent hope into a reliable, repeatable system. By combining simple, well-understood Linux tools — tar, rsync, rclone, database dump utilities, and cron scheduling — with sound principles like the 3-2-1 rule, proper logging, and regular restore testing, you can build a backup system that will actually save you when disaster strikes, not just when everything is already going fine.

Further Reading

• rsync Official Documentation
• rclone Documentation
• BorgBackup Documentation
• restic Documentation
• Cron man page
• MySQL mysqldump Reference
• PostgreSQL Backup and Restore Documentation

The post How to Perform Automated Backups in Linux appeared first on Abdul Wahab Junaid.

This article explains incremental backups from first principles — how they differ from full and differential backups, how to implement them on Linux using rsync, tar, and modern tools like restic and borgbackup, and how to structure a real backup rotation strategy around them.

Full vs. Incremental vs. Differential Backups

Understanding these three backup types — and the tradeoffs between them — is essential before implementing any backup strategy.

flowchart LR
    subgraph Full Backup Strategy
    F1[Full: Sun] --> F2[Full: Mon] --> F3[Full: Tue]
    end

flowchart LR
    subgraph Incremental Backup Strategy
    I1[Full: Sun] --> I2[Incremental: Mon changes only] --> I3[Incremental: Tue changes only] --> I4[Incremental: Wed changes only]
    end

With incremental backups, Monday’s backup only contains what changed between Sunday and Monday. Tuesday’s backup only contains what changed between Monday and Tuesday — and so on. To fully restore Wednesday’s state, you need the original full backup plus every incremental backup in the chain, applied in order.

Why Choose Incremental Backups?

The Tradeoff

The main downside is restore complexity and speed — recovering data means restoring the last full backup, then replaying every subsequent incremental backup in the correct order. A broken link anywhere in that chain can make later backups unusable.

Method 1: Incremental Backups with rsync and Hard Links

A classic and elegant technique uses rsync‘s --link-dest option combined with hard links, popularized by tools like rsnapshot. Each backup looks like a complete snapshot from the outside, but unchanged files are actually just hard links to the previous backup — using almost no extra disk space for unchanged data.

flowchart TD
    A[backup.2026-07-22 Full snapshot] -->|Hard links for unchanged files| B[backup.2026-07-23]
    B -->|Hard links for unchanged files| C[backup.2026-07-24]
    C -->|Only new/changed files use real disk space| D[Result: Each folder looks complete, but disk usage stays low]

Example Script

#!/bin/bash
SOURCE="/var/www"
BACKUP_ROOT="/backup/snapshots"
DATE=$(date +%F)
LATEST_LINK="$BACKUP_ROOT/latest"

mkdir -p "$BACKUP_ROOT"

rsync -av --delete \
  --link-dest="$LATEST_LINK" \
  "$SOURCE/" "$BACKUP_ROOT/$DATE/"

# Update the "latest" pointer for next time
rm -f "$LATEST_LINK"
ln -s "$BACKUP_ROOT/$DATE" "$LATEST_LINK"

#!/bin/bash
SOURCE="/var/www"
BACKUP_ROOT="/backup/snapshots"
DATE=$(date +%F)
LATEST_LINK="$BACKUP_ROOT/latest"

mkdir -p "$BACKUP_ROOT"

rsync -av --delete \
  --link-dest="$LATEST_LINK" \
  "$SOURCE/" "$BACKUP_ROOT/$DATE/"

# Update the "latest" pointer for next time
rm -f "$LATEST_LINK"
ln -s "$BACKUP_ROOT/$DATE" "$LATEST_LINK"

Each day’s folder ($BACKUP_ROOT/2026-07-24/) appears to contain a full copy of the source directory — you can cd into it and browse it like any normal folder — but unchanged files are hard-linked to yesterday’s backup, so they consume zero additional disk space.

Method 2: Incremental Backups with tar

tar has native support for incremental backups using a “snapshot file” that tracks file metadata between runs.

First Backup (Full)

tar --create \
    --file=/backup/full-2026-07-20.tar \
    --listed-incremental=/backup/snapshot.snar \
    /var/www

tar --create \
    --file=/backup/full-2026-07-20.tar \
    --listed-incremental=/backup/snapshot.snar \
    /var/www

Subsequent Backups (Incremental)

tar --create \
    --file=/backup/incr-2026-07-21.tar \
    --listed-incremental=/backup/snapshot.snar \
    /var/www

tar --create \
    --file=/backup/incr-2026-07-21.tar \
    --listed-incremental=/backup/snapshot.snar \
    /var/www

The --listed-incremental snapshot file (snapshot.snar) remembers exactly what was backed up last time — each subsequent run only includes files that are new or modified since the last snapshot update.

Restoring a Full Chain

cd /restore-target
tar --extract --listed-incremental=/dev/null --file=/backup/full-2026-07-20.tar
tar --extract --listed-incremental=/dev/null --file=/backup/incr-2026-07-21.tar
tar --extract --listed-incremental=/dev/null --file=/backup/incr-2026-07-22.tar

cd /restore-target
tar --extract --listed-incremental=/dev/null --file=/backup/full-2026-07-20.tar
tar --extract --listed-incremental=/dev/null --file=/backup/incr-2026-07-21.tar
tar --extract --listed-incremental=/dev/null --file=/backup/incr-2026-07-22.tar

Notice the extracts must happen in order — full, then each incremental in sequence.

Method 3: Modern Tools — restic and borgbackup

Modern backup tools like restic and borgbackup handle incremental logic automatically, with added benefits like deduplication and encryption built in — no manual snapshot management required.

restic Example

# Initialize a backup repository (once)
restic init --repo /backup/restic-repo

# Run a backup (restic automatically only stores new/changed data)
restic backup /var/www --repo /backup/restic-repo

# List all snapshots
restic snapshots --repo /backup/restic-repo

# Restore a specific snapshot
restic restore latest --target /restore --repo /backup/restic-repo

# Initialize a backup repository (once)
restic init --repo /backup/restic-repo

# Run a backup (restic automatically only stores new/changed data)
restic backup /var/www --repo /backup/restic-repo

# List all snapshots
restic snapshots --repo /backup/restic-repo

# Restore a specific snapshot
restic restore latest --target /restore --repo /backup/restic-repo

borgbackup Example

# Initialize a repository
borg init --encryption=repokey /backup/borg-repo

# Create an incremental backup (borg deduplicates automatically)
borg create /backup/borg-repo::backup-{now} /var/www

# List all backups
borg list /backup/borg-repo

# Restore a specific archive
borg extract /backup/borg-repo::backup-2026-07-24

# Initialize a repository
borg init --encryption=repokey /backup/borg-repo

# Create an incremental backup (borg deduplicates automatically)
borg create /backup/borg-repo::backup-{now} /var/www

# List all backups
borg list /backup/borg-repo

# Restore a specific archive
borg extract /backup/borg-repo::backup-2026-07-24

Both tools use content-based deduplication — meaning even if a large file is only partially modified, only the changed chunks are stored, not the entire file again. This is more efficient than traditional file-level incremental approaches.

Comparison Table: Incremental Backup Tools

Real-World Example: Backing Up a Growing Log/Data Server

Scenario: A company has a data ingestion server accumulating about 50 GB of new data files per day, with a total dataset of 5 TB. A full backup every night would take hours and consume enormous storage.

Solution using restic:

# Weekly full-equivalent baseline handled automatically by restic's dedup engine
0 1 * * * restic backup /data --repo /backup/restic-repo --tag daily

# Prune old snapshots weekly, keeping a sensible retention policy
0 3 * * 0 restic forget --repo /backup/restic-repo --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

# Weekly full-equivalent baseline handled automatically by restic's dedup engine
0 1 * * * restic backup /data --repo /backup/restic-repo --tag daily

# Prune old snapshots weekly, keeping a sensible retention policy
0 3 * * 0 restic forget --repo /backup/restic-repo --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune

Because restic deduplicates at the block level, even though 50 GB of new files are added daily, if those files share content with existing data (common in log formats, database exports, etc.), the actual stored increment can be far smaller than 50 GB — saving significant storage over time.

Cisco Example: Incremental Configuration Backups

While Cisco devices don’t have a native “incremental backup” concept for configs (configs are usually small enough for full backups), the same principle applies when managing large numbers of devices. A common pattern is to back up configs daily but only alert or store a new version if the configuration actually changed — effectively an application-level incremental strategy:

# Simplified logic: only save a new config backup if it differs from the last one
import hashlib

def config_changed(new_config, last_backup_path):
    with open(last_backup_path, 'rb') as f:
        old_hash = hashlib.sha256(f.read()).hexdigest()
    new_hash = hashlib.sha256(new_config.encode()).hexdigest()
    return old_hash != new_hash

# Simplified logic: only save a new config backup if it differs from the last one
import hashlib

def config_changed(new_config, last_backup_path):
    with open(last_backup_path, 'rb') as f:
        old_hash = hashlib.sha256(f.read()).hexdigest()
    new_hash = hashlib.sha256(new_config.encode()).hexdigest()
    return old_hash != new_hash

This pattern — hash comparison to detect actual changes — is the same underlying idea that makes incremental backups efficient: don’t store what hasn’t changed.

Python Example: A Custom Incremental Backup Script Using Hashes

import os
import hashlib
import shutil
import json
from datetime import date

SOURCE_DIR = "/var/www"
BACKUP_DIR = "/backup/incremental"
MANIFEST_FILE = os.path.join(BACKUP_DIR, "manifest.json")

def file_hash(path):
    h = hashlib.sha256()
    with open(path, 'rb') as f:
        while chunk := f.read(8192):
            h.update(chunk)
    return h.hexdigest()

def load_manifest():
    if os.path.exists(MANIFEST_FILE):
        with open(MANIFEST_FILE) as f:
            return json.load(f)
    return {}

def save_manifest(manifest):
    with open(MANIFEST_FILE, 'w') as f:
        json.dump(manifest, f)

def run_incremental_backup():
    manifest = load_manifest()
    today_dir = os.path.join(BACKUP_DIR, str(date.today()))
    os.makedirs(today_dir, exist_ok=True)

    changed_count = 0
    for root, _, files in os.walk(SOURCE_DIR):
        for name in files:
            full_path = os.path.join(root, name)
            rel_path = os.path.relpath(full_path, SOURCE_DIR)
            current_hash = file_hash(full_path)

            if manifest.get(rel_path) != current_hash:
                dest_path = os.path.join(today_dir, rel_path)
                os.makedirs(os.path.dirname(dest_path), exist_ok=True)
                shutil.copy2(full_path, dest_path)
                manifest[rel_path] = current_hash
                changed_count += 1

    save_manifest(manifest)
    print(f"Incremental backup complete: {changed_count} files changed")

run_incremental_backup()

import os
import hashlib
import shutil
import json
from datetime import date

SOURCE_DIR = "/var/www"
BACKUP_DIR = "/backup/incremental"
MANIFEST_FILE = os.path.join(BACKUP_DIR, "manifest.json")

def file_hash(path):
    h = hashlib.sha256()
    with open(path, 'rb') as f:
        while chunk := f.read(8192):
            h.update(chunk)
    return h.hexdigest()

def load_manifest():
    if os.path.exists(MANIFEST_FILE):
        with open(MANIFEST_FILE) as f:
            return json.load(f)
    return {}

def save_manifest(manifest):
    with open(MANIFEST_FILE, 'w') as f:
        json.dump(manifest, f)

def run_incremental_backup():
    manifest = load_manifest()
    today_dir = os.path.join(BACKUP_DIR, str(date.today()))
    os.makedirs(today_dir, exist_ok=True)

    changed_count = 0
    for root, _, files in os.walk(SOURCE_DIR):
        for name in files:
            full_path = os.path.join(root, name)
            rel_path = os.path.relpath(full_path, SOURCE_DIR)
            current_hash = file_hash(full_path)

            if manifest.get(rel_path) != current_hash:
                dest_path = os.path.join(today_dir, rel_path)
                os.makedirs(os.path.dirname(dest_path), exist_ok=True)
                shutil.copy2(full_path, dest_path)
                manifest[rel_path] = current_hash
                changed_count += 1

    save_manifest(manifest)
    print(f"Incremental backup complete: {changed_count} files changed")

run_incremental_backup()

This script only copies files whose SHA-256 hash has changed since the last run — the core principle behind every incremental backup tool, written from scratch to illustrate exactly how they work under the hood.

Designing a Retention Strategy (GFS: Grandfather-Father-Son)

A common industry-standard rotation scheme for incremental backups is GFS:

flowchart TD
    A[Daily Incrementals - Son] --> B[Weekly Rollup - Father]
    B --> C[Monthly Rollup - Grandfather]

This gives you fine-grained recent recovery points (daily, for the last week) while still retaining longer-term history (monthly, for the last year) without keeping 365 individual daily backups forever.

Best Practices

• Always pair incrementals with periodic full backups — an unbroken chain of 200 incrementals with no recent full backup is fragile and slow to restore.
• Test the entire restore chain periodically, not just the latest incremental — a broken link anywhere breaks the whole chain.
• Use tools with built-in deduplication (restic, borgbackup) for the best balance of simplicity and efficiency.
• Automate retention/pruning so incremental chains don’t grow forever.
• Monitor backup job success/failure with alerts — a silently failing incremental chain can go unnoticed for weeks.
• Encrypt incremental backups, especially when stored offsite or in the cloud.
• Document the exact restore procedure, including the order of operations, so anyone on the team can execute a recovery under pressure.

Troubleshooting

Summary

Incremental backups are the practical answer to the real-world constraints of storage, bandwidth, and time. By only capturing what has changed since the last backup — whether through rsync hard-linking, tar‘s snapshot tracking, or modern deduplicating tools like restic and borgbackup — you can back up far more frequently, use dramatically less storage, and still maintain a complete, restorable history of your data. The key is pairing incrementals with a sound retention strategy and testing restores regularly, so the speed and efficiency gains never come at the cost of reliability.

Further Reading

• restic Documentation
• BorgBackup Documentation
• GNU tar Incremental Backups Manual
• rsync –link-dest Documentation
• rsnapshot Official Site
• Backup Rotation Schemes – GFS Explained

The post How to Perform Incremental Backups in Linux appeared first on Abdul Wahab Junaid.

This article explains tape backups on Linux from the ground up — how tape drives work, the tools used to control them (mt and tar), how to build a rotation strategy, and how modern approaches like LTFS make tape almost as easy to browse as a regular hard drive.

Why Tape Still Matters

The tradeoff, of course, is speed — tape is sequential-access media, meaning to read a file near the end of a tape, the drive must physically wind through everything before it. This makes tape unsuitable for frequently-accessed data, but ideal for long-term archives and disaster-recovery-of-last-resort backups.

How Tape Storage Works

Unlike a hard drive or SSD, which can jump instantly to any location on the media (random access), tape is a sequential access medium — data is written and read in a straight line, like an old cassette tape.

flowchart LR
    A[Tape Start] --> B[File 1] --> C[File 2] --> D[File 3] --> E[...] --> F[Tape End]

To read “File 3,” the drive must physically wind past File 1 and File 2 first (unless it uses an index, discussed later). This is the fundamental tradeoff of tape: incredible cost-efficiency and durability, at the cost of slow random access.

Linux Tape Devices

When a tape drive is connected to a Linux system (often via SAS, Fibre Channel, or USB for smaller autoloaders), it typically appears as a device like:

/dev/st0     # rewinding tape device
/dev/nst0    # non-rewinding tape device

/dev/st0     # rewinding tape device
/dev/nst0    # non-rewinding tape device

Rewinding vs. Non-Rewinding Devices

For backup work involving multiple files/archives on a single tape, you almost always want the non-rewinding device (/dev/nst0), so each write picks up where the last one left off instead of overwriting from the start.

Step 1: Install Tape Tools

sudo apt install mt-st tar -y        # Debian/Ubuntu
sudo dnf install mt-st tar -y        # RHEL/CentOS

sudo apt install mt-st tar -y        # Debian/Ubuntu
sudo dnf install mt-st tar -y        # RHEL/CentOS

mt (“magnetic tape control”) is the primary tool for controlling tape drive operations — rewinding, ejecting, seeking, and erasing.

Step 2: Basic Tape Operations with mt

# Check tape drive status
mt -f /dev/nst0 status

# Rewind the tape to the beginning
mt -f /dev/st0 rewind

# Eject the tape
mt -f /dev/st0 offline

# Erase a tape completely
mt -f /dev/st0 erase

# Move forward by 2 file marks (skip past 2 archives)
mt -f /dev/nst0 fsf 2

# Move backward by 1 file mark
mt -f /dev/nst0 bsf 1

# Check tape drive status
mt -f /dev/nst0 status

# Rewind the tape to the beginning
mt -f /dev/st0 rewind

# Eject the tape
mt -f /dev/st0 offline

# Erase a tape completely
mt -f /dev/st0 erase

# Move forward by 2 file marks (skip past 2 archives)
mt -f /dev/nst0 fsf 2

# Move backward by 1 file mark
mt -f /dev/nst0 bsf 1

Step 3: Writing a Backup to Tape with tar

tar was originally designed for exactly this purpose — its name literally stands for Tape ARchive.

Writing Data to Tape

sudo tar -cvf /dev/nst0 /var/www /etc

sudo tar -cvf /dev/nst0 /var/www /etc

This writes an archive of /var/www and /etc directly to the tape device, without creating an intermediate file on disk.

Writing Multiple Archives to the Same Tape

Because we used the non-rewinding device, we can write a second archive right after the first without overwriting it:

sudo tar -cvf /dev/nst0 /var/www
sudo tar -cvf /dev/nst0 /home
sudo tar -cvf /dev/nst0 /etc

sudo tar -cvf /dev/nst0 /var/www
sudo tar -cvf /dev/nst0 /home
sudo tar -cvf /dev/nst0 /etc

Each tar command writes one “file” onto the tape, separated by a file mark, one after another:

flowchart LR
    A[Tape Start] --> B["Archive 1: /var/www"] --> C["Archive 2: /home"] --> D["Archive 3: /etc"] --> E[Tape End]

Reading Data Back from Tape

First, rewind to the beginning:

sudo mt -f /dev/st0 rewind

sudo mt -f /dev/st0 rewind

Then extract the first archive:

sudo tar -xvf /dev/nst0

sudo tar -xvf /dev/nst0

To get to the second archive (/home), skip forward past the first file mark, then extract:

sudo mt -f /dev/nst0 fsf 1
sudo tar -xvf /dev/nst0

sudo mt -f /dev/nst0 fsf 1
sudo tar -xvf /dev/nst0

Listing Contents Without Extracting

sudo tar -tvf /dev/nst0

sudo tar -tvf /dev/nst0

Step 4: Compression Considerations

Unlike disk backups, it’s usually best to let the tape drive’s own hardware compression handle compression rather than software compression like gzip, because:

• Hardware compression is extremely fast (built into the drive controller)
• Pre-compressed data (e.g., via tar -z) doesn’t compress further and may even slightly increase in size when passed through the drive’s compression engine
• LTO drives typically achieve roughly 2:1 compression ratios on typical data

If you do want software compression for portability reasons, use it consistently and be aware it may reduce the tape drive’s own compression efficiency.

LTFS: Making Tape Behave Like a Disk

LTFS (Linear Tape File System) is a modern standard that lets you mount a tape and browse it like a regular filesystem — with visible files and folders — instead of using raw sequential tar streams.

sudo apt install ltfs -y

# Format a tape with LTFS
sudo mkltfs -d /dev/nst0

# Mount it like a regular filesystem
sudo mkdir /mnt/tape
sudo ltfs -o devname=/dev/nst0 /mnt/tape

# Now you can use normal file commands!
cp -r /var/www /mnt/tape/
ls /mnt/tape/

# Unmount when finished
sudo umount /mnt/tape

sudo apt install ltfs -y

# Format a tape with LTFS
sudo mkltfs -d /dev/nst0

# Mount it like a regular filesystem
sudo mkdir /mnt/tape
sudo ltfs -o devname=/dev/nst0 /mnt/tape

# Now you can use normal file commands!
cp -r /var/www /mnt/tape/
ls /mnt/tape/

# Unmount when finished
sudo umount /mnt/tape

LTFS trades away a small amount of the raw efficiency of tar streaming in exchange for dramatically improved usability — a huge win for organizations that need occasional random access to archived files without a full tape read-through.

Comparison Table: Tape Backup Approaches

Real-World Example: Compliance Archival for a Financial Company

Scenario: A financial services company is legally required to retain transaction records for 7 years, with data that must be stored offline (air-gapped) for security compliance.

Solution:

1. Monthly, a full database export and document archive is created.
2. The archive is written to two LTO tape cartridges (tar -cvf /dev/nst0 ...), one kept onsite in a fireproof safe, one sent to an offsite secure storage facility — following the 3-2-1 principle from general backup strategy.
3. Each tape is labeled with the date and a checksum file is also written to the tape for later integrity verification.
4. Tapes older than 7 years are securely destroyed per company data retention policy.

Because the tapes are physically disconnected from any network after writing, they are completely immune to ransomware, remote attacks, or accidental deletion — a property no purely online backup system can fully match.

Cisco Example: Network Bandwidth Planning for Tape Libraries

While Cisco hardware doesn’t interact with tape directly, tape backup systems (especially large tape libraries/autoloaders) often sit on a dedicated backup network segment to avoid saturating production bandwidth during large backup windows. A typical Cisco QoS configuration prioritizes production traffic over scheduled backup traffic:

class-map match-all BACKUP-TRAFFIC
 match access-group name BACKUP-ACL

policy-map WAN-QOS
 class BACKUP-TRAFFIC
  bandwidth percent 20
  set dscp af11
 class class-default
  bandwidth percent 80

class-map match-all BACKUP-TRAFFIC
 match access-group name BACKUP-ACL

policy-map WAN-QOS
 class BACKUP-TRAFFIC
  bandwidth percent 20
  set dscp af11
 class class-default
  bandwidth percent 80

This ensures that when a large backup job saturates the network transferring data to a tape library, it doesn’t starve critical production traffic like VoIP or customer-facing applications.

Python Example: Automating Tape Backup Verification

Verifying tape backups is critical — you don’t want to discover a tape is unreadable only when you desperately need to restore from it. Here’s a script that automates writing a checksum manifest alongside a tape backup:

import subprocess
import hashlib
import os
import datetime

SOURCE_DIRS = ["/var/www", "/etc"]
TAPE_DEVICE = "/dev/nst0"
REWIND_DEVICE = "/dev/st0"
LOG_FILE = "/var/log/tape-backup.log"

def calculate_checksums(directories):
    manifest = {}
    for directory in directories:
        for root, _, files in os.walk(directory):
            for name in files:
                path = os.path.join(root, name)
                try:
                    h = hashlib.sha256()
                    with open(path, 'rb') as f:
                        while chunk := f.read(8192):
                            h.update(chunk)
                    manifest[path] = h.hexdigest()
                except (PermissionError, FileNotFoundError):
                    continue
    return manifest

def write_to_tape(directories, device):
    cmd = ["tar", "-cvf", device] + directories
    result = subprocess.run(cmd, capture_output=True, text=True)
    return result.returncode == 0

def log(message):
    with open(LOG_FILE, "a") as f:
        f.write(f"[{datetime.datetime.now()}] {message}\n")

def run_tape_backup():
    subprocess.run(["mt", "-f", REWIND_DEVICE, "rewind"])

    log("Calculating pre-backup checksums...")
    manifest = calculate_checksums(SOURCE_DIRS)
    log(f"Checksummed {len(manifest)} files")

    log("Writing archive to tape...")
    success = write_to_tape(SOURCE_DIRS, TAPE_DEVICE)

    if success:
        log("Tape backup completed successfully")
    else:
        log("TAPE BACKUP FAILED")

    subprocess.run(["mt", "-f", REWIND_DEVICE, "rewind"])

if __name__ == "__main__":
    run_tape_backup()

import subprocess
import hashlib
import os
import datetime

SOURCE_DIRS = ["/var/www", "/etc"]
TAPE_DEVICE = "/dev/nst0"
REWIND_DEVICE = "/dev/st0"
LOG_FILE = "/var/log/tape-backup.log"

def calculate_checksums(directories):
    manifest = {}
    for directory in directories:
        for root, _, files in os.walk(directory):
            for name in files:
                path = os.path.join(root, name)
                try:
                    h = hashlib.sha256()
                    with open(path, 'rb') as f:
                        while chunk := f.read(8192):
                            h.update(chunk)
                    manifest[path] = h.hexdigest()
                except (PermissionError, FileNotFoundError):
                    continue
    return manifest

def write_to_tape(directories, device):
    cmd = ["tar", "-cvf", device] + directories
    result = subprocess.run(cmd, capture_output=True, text=True)
    return result.returncode == 0

def log(message):
    with open(LOG_FILE, "a") as f:
        f.write(f"[{datetime.datetime.now()}] {message}\n")

def run_tape_backup():
    subprocess.run(["mt", "-f", REWIND_DEVICE, "rewind"])

    log("Calculating pre-backup checksums...")
    manifest = calculate_checksums(SOURCE_DIRS)
    log(f"Checksummed {len(manifest)} files")

    log("Writing archive to tape...")
    success = write_to_tape(SOURCE_DIRS, TAPE_DEVICE)

    if success:
        log("Tape backup completed successfully")
    else:
        log("TAPE BACKUP FAILED")

    subprocess.run(["mt", "-f", REWIND_DEVICE, "rewind"])

if __name__ == "__main__":
    run_tape_backup()

The checksum manifest can later be compared against a restored copy to confirm data integrity — an essential step for any archival system meant to be trusted years down the line.

Best Practices

• Always use the non-rewinding device (/dev/nst0) when writing multiple archives to a single tape.
• Label every tape physically and digitally — with date, contents summary, and retention/expiry date.
• Store tapes properly — cool, dry, magnetically shielded environments extend tape lifespan significantly.
• Rotate tapes off-site for disaster recovery, following the 3-2-1 backup principle.
• Periodically test-read old tapes — media degrades, and drives eventually stop supporting very old formats.
• Use hardware compression on the drive rather than double-compressing with software tools.
• Keep a tape catalog/index (via LTFS, or dedicated backup software) so you don’t have to blindly search through tapes to find a specific file.
• Plan for drive obsolescence — LTO drives typically read back 1–2 generations and write 1 generation back; migrate old tapes to new formats periodically.

Troubleshooting

Useful Diagnostic Commands

# Check detected tape devices
lsscsi | grep tape

# Check current tape drive status
mt -f /dev/nst0 status

# Test read without extracting
tar -tvf /dev/nst0

# Check kernel messages for tape drive errors
dmesg | grep -i tape

# Check detected tape devices
lsscsi | grep tape

# Check current tape drive status
mt -f /dev/nst0 status

# Test read without extracting
tar -tvf /dev/nst0

# Check kernel messages for tape drive errors
dmesg | grep -i tape

Summary

Tape storage may not be flashy, but it remains an irreplaceable part of a mature backup and archival strategy — offering unmatched cost efficiency, long-term durability, and true air-gapped security that no online backup can fully replicate. By understanding Linux tape device semantics (/dev/st0 vs /dev/nst0), mastering mt and tar fundamentals, and optionally layering on LTFS for usability, you can build a tape backup system that will reliably protect your organization’s most critical long-term data for decades.

Further Reading

• GNU tar Manual – Tape Backups
• mt(1) man page
• LTFS Format Specification – SNIA
• LTO Ultrium Official Site
• Bacula Open Source Backup Software
• Amanda Network Backup
• 3-2-1 Backup Strategy Explained – US-CERT

The post How to Back Up Data on Tapes in Linux appeared first on Abdul Wahab Junaid.

In this article, we will explain, from first principles, what a multi-volume archive is, why it exists, how the Linux tar command supports it, and how to create and restore one step by step. We’ll use simple English, real command-line examples, diagrams, and a troubleshooting guide so that both beginners and experienced administrators can use this as a reference.

What Is an Archive, Really?

Before we talk about “multi-volume” anything, let’s define an archive. An archive is a single file that contains many other files and directories, bundled together with their names, permissions, and directory structure preserved. On Linux, the classic tool for this is tar (short for Tape ARchiver — a name that hints at its origins in the days of magnetic tape backups).

A normal archive command looks like this:

tar -cvf backup.tar /home/user/documents

tar -cvf backup.tar /home/user/documents

Here:

• -c means create a new archive
• -v means verbose (show file names as they’re archived)
• -f means the next argument is the filename of the archive

This creates one single file, backup.tar, containing everything under /home/user/documents.

The Problem: What If the Data Is Too Big?

Imagine you have 50 GB of data to back up, but your only available media is a set of 4.7 GB DVDs, or a series of 8 GB USB sticks. A single .tar file of 50 GB simply will not fit on any single piece of media. This is the exact problem tape archiving faced decades ago — tapes had fixed lengths, and a backup often needed more tape than one reel could hold.

The solution is to split the single archive into multiple smaller pieces, called volumes, where each volume fits on one piece of media, and tar knows how to prompt you to insert or specify the next volume when the current one is full.

This is different from simply splitting a file into random pieces using a tool like split. A multi-volume tar archive is tar-aware — meaning tar itself understands the volume boundaries, tracks file continuity across volumes (even if a single large file is cut in half between two volumes), and can reassemble everything correctly on restore.

How Multi-Volume Archives Work (Conceptually)

Think of it like packing a very large shipment into several boxes because no single box is big enough. Each box (volume) is labeled with a sequence number. When you unpack, you must open the boxes in the correct order — box 1, then box 2, then box 3 — otherwise the contents won’t make sense, especially if one item was too big to fit in a single box and had to be split across two.

flowchart LR
    A[Original Data 50GB] --> B[tar --multi-volume]
    B --> C[Volume 1 - 4.7GB]
    B --> D[Volume 2 - 4.7GB]
    B --> E[Volume 3 - 4.7GB]
    B --> F[... more volumes ...]
    C --> G[Restore: tar -M]
    D --> G
    E --> G
    F --> G
    G --> H[Original Data Restored]

Creating a Multi-Volume Archive

The tar command supports multi-volume archiving using the -M (or --multi-volume) flag, combined with -L to specify the size limit per volume (in units of 1024 bytes, i.e., KB), or you can let tar prompt interactively when a volume boundary is reached.

Basic Example

Suppose we want to back up /data into volumes of 100 MB each:

tar --create --multi-volume --tape-length=102400 --file=backup.tar.vol1 /data

tar --create --multi-volume --tape-length=102400 --file=backup.tar.vol1 /data

Explanation:

• --create – create a new archive
• --multi-volume (-M) – enable multi-volume mode
• --tape-length=102400 (-L) – set the volume size to 102400 KB (100 MB); this name is a holdover from tape backup terminology
• --file=backup.tar.vol1 – the name of the first volume

When tar reaches the size limit, it will pause and ask:

Prepare volume #2 for 'backup.tar.vol1' and hit return:

Prepare volume #2 for 'backup.tar.vol1' and hit return:

At this point, in the old tape-based world, you’d physically swap tapes. On a modern system writing to files (for example, if you’re staging backups on separate USB drives one at a time), you type a new filename when prompted, or use the -F (--info-script) option to run a script that handles the swap automatically.

Non-Interactive Multi-Volume Backup Using a Naming Pattern

For unattended backups, it’s common to combine -M with a script, or to just create the volumes as separate named files without needing manual intervention, like this:

tar -M -L 102400 -cvf backup-vol-%d.tar /data

tar -M -L 102400 -cvf backup-vol-%d.tar /data

Here %d is replaced with the volume number automatically by tar in newer GNU tar versions, producing files like backup-vol-1.tar, backup-vol-2.tar, and so on.

Practical Example: Backing Up to DVD-Sized Volumes

DVDs typically hold about 4.7 GB (4,700,000 KB, though the “real” formatted capacity is slightly less). A conservative volume size command:

tar --create --multi-volume --tape-length=4500000 \
    --file=/mnt/dvd-staging/backup.tar /var/www /etc /home

tar --create --multi-volume --tape-length=4500000 \
    --file=/mnt/dvd-staging/backup.tar /var/www /etc /home

This creates volume files sized to comfortably fit on a 4.7 GB DVD, leaving a small safety margin for filesystem overhead.

Restoring a Multi-Volume Archive

Restoring uses the same -M flag but with the -x (extract) option instead of -c (create):

tar --extract --multi-volume --file=backup.tar.vol1

tar --extract --multi-volume --file=backup.tar.vol1

When tar reaches the end of the first volume’s data, it will prompt:

Prepare volume #2 for 'backup.tar.vol1' and hit return:

Prepare volume #2 for 'backup.tar.vol1' and hit return:

If your volumes are named sequentially (backup.tar.vol1, backup.tar.vol2, …), you can type the next filename at the prompt, or better, use the -F info-script option to automate the process:

tar -Mx -f backup.tar.vol1 -F ./next-volume.sh

tar -Mx -f backup.tar.vol1 -F ./next-volume.sh

Where next-volume.sh is a small script that tells tar the name of the next volume automatically, based on the TAR_VOLUME environment variable that tar sets for the script.

Example next-volume.sh Script

#!/bin/bash
# tar calls this script when it needs the next volume
# It expects the script to echo the next volume's filename to stdout
echo "backup.tar.vol${TAR_VOLUME}"

#!/bin/bash
# tar calls this script when it needs the next volume
# It expects the script to echo the next volume's filename to stdout
echo "backup.tar.vol${TAR_VOLUME}"

Make it executable:

chmod +x next-volume.sh

chmod +x next-volume.sh

A Complete Walkthrough Example

Let’s walk through a full, realistic scenario: backing up a 10 GB directory into 2 GB volumes on a Linux server, then restoring it onto a different machine.

Step 1: Create the archive

tar --create --multi-volume --tape-length=2097152 \
    --file=/backups/website-backup.tar /var/www/html

tar --create --multi-volume --tape-length=2097152 \
    --file=/backups/website-backup.tar /var/www/html

Step 2: Respond to volume prompts (or automate with a script)

Prepare volume #2 for '/backups/website-backup.tar' and hit return:
n website-backup.tar.2

Prepare volume #2 for '/backups/website-backup.tar' and hit return:
n website-backup.tar.2

Typing n website-backup.tar.2 tells tar the new filename for volume 2.

Step 3: Verify the volumes exist

ls -lh /backups/website-backup.tar*

ls -lh /backups/website-backup.tar*

Step 4: Transfer volumes to the restore target (using scp, external drive, etc.)

scp /backups/website-backup.tar* admin@newserver:/restore/

scp /backups/website-backup.tar* admin@newserver:/restore/

Step 5: Restore on the new server

cd /restore
tar --extract --multi-volume --file=website-backup.tar

cd /restore
tar --extract --multi-volume --file=website-backup.tar

Respond to volume prompts the same way as during creation.

Step 6: Verify the restored data

diff -r /var/www/html /restore/var/www/html

diff -r /var/www/html /restore/var/www/html

Comparison: Single-Volume vs. Multi-Volume Archives

Real-World Use Cases

1. Offline data transport: Transferring a large database dump to an air-gapped, secure network via a stack of USB drives, where no single drive is large enough.
2. Legacy tape backup systems: Enterprises still running LTO tape drives for compliance-driven long-term archival often rely on multi-volume tar behavior baked into their backup software.
3. DVD/Blu-ray archival: Small businesses without cloud backup budgets sometimes still archive project files to optical media in multi-volume sets.
4. Bandwidth-limited cloud uploads: Splitting a huge archive into fixed-size chunks so each chunk can be retried independently if an upload fails, without re-uploading everything.

Best Practices

• Always verify your volumes after creation. Use tar --list --multi-volume --file=vol1 to confirm the archive’s table of contents is intact before you rely on it.
• Keep volume naming consistent and sequential. Avoid renaming volumes after creation; tar expects to find them by the name pattern you used, or by prompt-response, in the correct order.
• Document your volume size choice. Write down the exact --tape-length value used, so future restores (possibly by a different administrator) know what to expect.
• Test restores regularly. A backup you have never restored is not a real backup. Periodically do a full multi-volume restore into a scratch directory to confirm every volume works.
• Use checksums. Generate an sha256sum for each volume file right after backup, and store the checksums separately, so you can detect corruption before attempting a restore.
• Automate volume swapping wherever possible using -F info-scripts to avoid human error during long unattended backup windows.
• Store volumes in the correct order if using physical media (label them clearly: Volume 1 of 5, Volume 2 of 5, etc.).

Troubleshooting

Problem: tar: This does not look like a tar archive

This usually happens when you try to extract starting from the wrong volume, or a volume file got corrupted or truncated during transfer. Always start extraction from volume 1, and verify the file sizes match the source.

Problem: tar doesn’t prompt for the next volume in a non-interactive script

If you’re running tar inside a script or cron job, an interactive prompt will hang forever waiting for input. Always use the -F info-script option for unattended multi-volume operations instead of relying on interactive prompts.

Problem: Restored files are incomplete or truncated

This is almost always a sign that a volume was skipped, corrupted, or restored out of order. Re-check the sequence of volume files and re-verify their checksums against the ones generated at backup time.

Problem: Volume sizes don’t match what you specified

Remember that --tape-length is measured in kilobytes (1024-byte units), and the actual final volume in a set will normally be smaller than the others, since it just contains the remaining data. This is expected behavior, not an error.

Problem: Insufficient permissions when restoring system files

Multi-volume restores that include system directories like /etc typically need to run as root:

sudo tar --extract --multi-volume --file=backup.tar.vol1

sudo tar --extract --multi-volume --file=backup.tar.vol1

Conclusion

Multi-volume archives solve a very old but still very real problem: how do you back up data that’s larger than any single piece of media you have available? By understanding how tar‘s -M and -L options work, how volume prompts and info-scripts function, and how to verify and automate the process, you can confidently back up and restore datasets of any size — from a home server’s photo collection to an enterprise database spanning dozens of gigabytes.

The key takeaways are: always test your restores, automate volume handling with scripts for unattended jobs, keep volumes in strict sequential order, and verify integrity with checksums. With these practices in place, multi-volume archiving becomes a reliable, professional-grade backup strategy rather than a source of anxiety.

Further Reading

• GNU Tar Manual — Multi-Volume Archives
• GNU Tar Manual — Full Reference
• Linux man page for tar
• Red Hat: Backing up and restoring data
• Arch Wiki: Tar
• Debian Administrator’s Handbook — Backup

The post How to Back Up and Restore a Multi-Volume Archive in Linux appeared first on Abdul Wahab Junaid.

This article explains, from first principles, what an archive is, how the tar command works, how to create and restore a single-volume archive, how compression fits in, and how to troubleshoot common problems — all illustrated with practical, real-world examples.

What Is a Single-Volume Archive?

A single-volume archive is exactly what it sounds like: one file that contains a bundle of other files and directories, with no need to split the data across multiple pieces. Compare this to a multi-volume archive (used when data is too large for one piece of media), which we cover in a separate article.

For most everyday backup jobs — a home directory, a website’s files, a set of configuration files — a single-volume archive is all you need, because modern storage (hard drives, SSDs, cloud storage) can typically hold gigabytes or terabytes in a single file without any issue.

flowchart TD
    A[Source Files and Directories] -->|tar -cvf| B[Single Archive File: backup.tar]
    B -->|tar -xvf| A2[Restored Files and Directories]

The tar Command: The Foundation

The tar utility (Tape Archiver) is the standard Linux tool for creating archives. Its basic syntax is:

tar [options] -f archive-name.tar file-or-directory

tar [options] -f archive-name.tar file-or-directory

Creating an Archive

tar -cvf home-backup.tar /home/username

tar -cvf home-backup.tar /home/username

Breaking this down:

• -c = create a new archive
• -v = verbose, print each filename as it’s processed
• -f = specify the filename of the archive (must be followed immediately by the filename)

This command bundles everything under /home/username into a single file called home-backup.tar.

Listing Contents Without Extracting

Before restoring, it’s good practice to check what’s inside an archive:

tar -tvf home-backup.tar

tar -tvf home-backup.tar

The -t flag lists the table of contents.

Restoring (Extracting) an Archive

tar -xvf home-backup.tar

tar -xvf home-backup.tar

• -x = extract
• Files are restored relative to the current directory, preserving the original directory structure recorded in the archive.

To restore to a specific location:

tar -xvf home-backup.tar -C /restore/destination

tar -xvf home-backup.tar -C /restore/destination

The -C flag changes the extraction directory before extracting.

Adding Compression

A plain tar file is not compressed — it’s just a bundle. To save space, you compress it, typically with gzip or bzip2 or the newer xz.

Creating a Compressed Archive

tar -czvf home-backup.tar.gz /home/username

tar -czvf home-backup.tar.gz /home/username

The -z flag tells tar to pipe the output through gzip.

For better compression at the cost of speed:

tar -cjvf home-backup.tar.bz2 /home/username   # bzip2
tar -cJvf home-backup.tar.xz /home/username    # xz

tar -cjvf home-backup.tar.bz2 /home/username   # bzip2
tar -cJvf home-backup.tar.xz /home/username    # xz

Restoring a Compressed Archive

tar -xzvf home-backup.tar.gz
tar -xjvf home-backup.tar.bz2
tar -xJvf home-backup.tar.xz

tar -xzvf home-backup.tar.gz
tar -xjvf home-backup.tar.bz2
tar -xJvf home-backup.tar.xz

Modern GNU tar can actually auto-detect the compression type even without the -z/-j/-J flag, so tar -xvf home-backup.tar.gz will often “just work” — but specifying the flag explicitly is still good practice for clarity and portability.

Comparison Table: Compression Options

A Practical, Real-World Example

Let’s back up an Nginx web server’s configuration and content directory before making risky changes.

Step 1: Create the backup

sudo tar -czvf /backups/nginx-backup-$(date +%F).tar.gz /etc/nginx /var/www

sudo tar -czvf /backups/nginx-backup-$(date +%F).tar.gz /etc/nginx /var/www

This uses $(date +%F) to automatically insert today’s date (e.g., 2026-07-24) into the filename, so backups don’t overwrite each other.

Step 2: Confirm it worked

ls -lh /backups/
tar -tzvf /backups/nginx-backup-2026-07-24.tar.gz | head -20

ls -lh /backups/
tar -tzvf /backups/nginx-backup-2026-07-24.tar.gz | head -20

Step 3: Simulate a disaster — restore it

sudo tar -xzvf /backups/nginx-backup-2026-07-24.tar.gz -C /

sudo tar -xzvf /backups/nginx-backup-2026-07-24.tar.gz -C /

Because the archive was created with absolute paths (/etc/nginx, /var/www), extracting with -C / restores the files to their original locations.

Preserving Permissions and Ownership

By default, tar preserves file permissions, ownership, and timestamps as recorded in the archive — but only if you’re extracting as root. If you extract as a normal user, ownership may be changed to that user instead.

To force preservation of original ownership during extraction (as root):

sudo tar -xpvf home-backup.tar

sudo tar -xpvf home-backup.tar

The -p flag means preserve permissions.

Excluding Files From a Backup

Often you don’t want everything in a directory — for example, you might want to skip cache files or log files:

tar -czvf project-backup.tar.gz --exclude='*.log' --exclude='node_modules' /srv/project

tar -czvf project-backup.tar.gz --exclude='*.log' --exclude='node_modules' /srv/project

You can also use an exclude file listing multiple patterns:

tar -czvf project-backup.tar.gz -X excludes.txt /srv/project

tar -czvf project-backup.tar.gz -X excludes.txt /srv/project

Where excludes.txt contains:

*.log
*.tmp
node_modules/
.git/

*.log
*.tmp
node_modules/
.git/

Verifying Archive Integrity

Never trust a backup you haven’t verified. Two common approaches:

1. Compare against source using diff:

tar -xzvf backup.tar.gz -C /tmp/verify
diff -r /home/username /tmp/verify/home/username

tar -xzvf backup.tar.gz -C /tmp/verify
diff -r /home/username /tmp/verify/home/username

2. Generate and check a checksum:

sha256sum backup.tar.gz > backup.tar.gz.sha256
sha256sum -c backup.tar.gz.sha256

sha256sum backup.tar.gz > backup.tar.gz.sha256
sha256sum -c backup.tar.gz.sha256

Automating Backups With cron

A single-volume archive backup is a perfect candidate for automation. Here’s a cron job that backs up /etc every night at 2 AM:

0 2 * * * /usr/bin/tar -czf /backups/etc-backup-$(date +\%F).tar.gz /etc

0 2 * * * /usr/bin/tar -czf /backups/etc-backup-$(date +\%F).tar.gz /etc

Note the escaped % (\%) — cron interprets unescaped % characters as newlines, so they must be escaped inside crontab entries.

Real-World Use Cases

1. Website migrations: Archiving an entire web application directory before moving it to a new server.
2. Configuration snapshots: Taking a tar snapshot of /etc before a major system upgrade, so changes can be rolled back if something breaks.
3. Developer environment backups: Archiving a project directory (excluding build artifacts) before a risky refactor.
4. User data migration: Backing up a single user’s home directory before reinstalling the OS.

Best Practices

• Always test extraction in a scratch directory before trusting a backup for disaster recovery.
• Use compression thoughtfully — gzip for speed, xz for maximum space savings on long-term cold storage.
• Include a timestamp in the filename so successive backups don’t silently overwrite each other.
• Exclude unnecessary files (caches, logs, build artifacts) to keep archives lean and restore times fast.
• Store backups off-machine. A backup stored only on the same disk as the original data offers no protection against disk failure.
• Automate with cron or systemd timers, and monitor for job failures (e.g., email alerts on non-zero exit codes).
• Document restore procedures so that anyone on the team, not just the person who created the backup, can perform a restore.

Troubleshooting

Problem: tar: Cannot open: Permission denied

You likely need sudo to read protected system files, or to write to the destination directory. Re-run with elevated privileges:

sudo tar -czvf backup.tar.gz /etc

sudo tar -czvf backup.tar.gz /etc

Problem: Archive is larger than expected

Check whether you’re accidentally including large, unnecessary directories like node_modules, .git, or log directories. Use --exclude to trim them out, or inspect with tar -tzvf backup.tar.gz | wc -l to count files.

Problem: gzip: stdin: not in gzip format

This means the file isn’t actually gzip-compressed, even though it might have a .gz extension — perhaps it’s a plain .tar that was renamed. Check with:

file backup.tar.gz

file backup.tar.gz

Problem: Restored files have the wrong owner

You likely extracted as a non-root user. Re-extract as root with -p to preserve original ownership:

sudo tar -xpvf backup.tar

sudo tar -xpvf backup.tar

Problem: “Not enough space” during extraction

Check available disk space with df -h before extracting large archives, and extract to a partition with sufficient free space.

Conclusion

The single-volume archive is the workhorse of Linux backups. With just a handful of tar flags — -c, -x, -v, -f, -z/-j/-J, and -C — you can confidently back up and restore anything from a single configuration file to an entire application directory. Combine this with compression, exclusion rules, integrity verification, and cron-based automation, and you have a simple, dependable, and completely free backup system built entirely from tools that ship with every Linux distribution.

Further Reading

• GNU Tar Manual
• tar(1) man page
• gzip(1) man page
• Arch Wiki: Tar
• Cron job syntax reference
• Red Hat System Administrator’s Guide — Backups

The post How to Back Up and Restore a Single-Volume Archive in Linux appeared first on Abdul Wahab Junaid.

This is a long read, but I have tried to structure it so a beginner can follow along from the basics and an experienced storage administrator can jump straight to the sections on tuning, troubleshooting, and enterprise deployment.

Why Performance Metrics Matter in the First Place

Every storage system — whether it is a single NVMe drive in a laptop or a multi-petabyte SAN array — is a chain of components: application, operating system, host bus adapter (HBA) or network interface card (NIC), fabric or network, controller, cache, and physical media. A chain is only as fast as its weakest link, and metrics are how I find that weak link before it becomes an outage.

Without metrics, storage administration is guesswork. With them, I can answer questions like:

• Is my storage array the bottleneck, or is it the network fabric?
• Is the application generating too many small random I/Os?
• Is my SSD wearing out faster than expected?
• Will this workload still perform well if I double the number of virtual machines?

Core Performance Metrics I Track

1. IOPS (Input/Output Operations Per Second)

IOPS tells me how many read or write operations a device or system can handle every second. It is the single most quoted metric in storage sizing conversations, but it is also the most misunderstood because IOPS numbers change dramatically based on block size and read/write mix.

A rough formula I use when estimating IOPS capability of spinning disks:

IOPS ≈ 1 / (Seek Time + Rotational Latency + Transfer Time)

For a 15K RPM enterprise HDD:

• Average seek time: ~3.5 ms
• Rotational latency: ~2 ms (half of 4ms per rotation at 15,000 RPM)
• Transfer time: negligible for small blocks

IOPS ≈ 1 / (0.0035 + 0.002) ≈ 180 IOPS per disk

Compare that to an enterprise NVMe SSD, which can deliver anywhere from 100,000 to over 1,000,000 IOPS depending on queue depth and block size. This gap is exactly why I always ask “what block size and queue depth were used?” before trusting any vendor IOPS number.

2. Throughput (MB/s or GB/s)

Throughput measures how much data moves per second. IOPS and throughput are related by block size:

Throughput = IOPS × Block Size

Example: 10,000 IOPS at a 4KB block size gives roughly 39 MB/s, while the same 10,000 IOPS at a 256KB block size gives roughly 2.5 GB/s. This is why a system tuned for database transaction logs (small, random I/O) looks completely different from one tuned for video streaming or backup jobs (large, sequential I/O).

3. Latency

Latency is the time between issuing an I/O request and receiving the acknowledgment. I consider this the most important metric of all, because users feel latency directly — nobody notices IOPS, but everybody notices a slow application.

4. Queue Depth

Queue depth is the number of outstanding I/O requests waiting to be serviced. A higher queue depth generally increases throughput and IOPS up to a saturation point, after which latency spikes sharply. I always look at queue depth alongside latency, never in isolation.

5. CPU Utilization on Storage Controllers and Hosts

Storage performance is not purely a disk problem. I have seen arrays with plenty of free IOPS capacity that were still slow because the storage controller’s CPU was pegged at 100% doing data reduction (deduplication/compression) or RAID parity calculations.

6. Cache Hit Ratio

Most storage systems and hosts use some form of read/write caching (DRAM, NVDIMM, or flash-based). The cache hit ratio tells me what percentage of requests are served from fast cache versus slower backend media.

Cache Hit Ratio (%) = (Cache Hits / Total Requests) × 100

A ratio above 90% for read-heavy workloads is generally considered healthy; anything lower and I start investigating working-set size versus cache size.

Host-Side and Storage-Side Tools I Rely On

Linux Host Tools

iostat — my go-to for a quick health check:

iostat -xz 2 5

This gives extended stats every 2 seconds, 5 times, showing %util, await (latency), r/s, w/s, and avgqu-sz (queue depth) per device.

vmstat — useful for correlating storage waits with CPU and memory pressure:

vmstat 1 10

sar — historical performance data collected by sysstat:

sar -d -f /var/log/sysstat/sa15

nvme-cli — for NVMe-specific health and performance data:

nvme smart-log /dev/nvme0

This shows temperature, percentage used (wear), and error counts directly from the drive’s SMART data.

Windows Host Tools

• Performance Monitor (perfmon) — I add counters like LogicalDisk\Avg. Disk sec/Read, LogicalDisk\Avg. Disk sec/Write, and LogicalDisk\Current Disk Queue Length.
• PowerShell Get-Counter: