Every Linux system administrator eventually runs into the same wall: you need to back up a huge amount of data — maybe hundreds of gigabytes of logs, databases, or user files — but the destination media can’t hold it all in one piece. Maybe you’re writing to a stack of DVDs, a set of USB flash drives, or old-school tape media with a fixed capacity. This is exactly the problem that multi-volume archives solve.
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/documentsHere:
-cmeans create a new archive-vmeans verbose (show file names as they’re archived)-fmeans 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 /dataExplanation:
--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: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 /dataHere %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 /homeThis 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.vol1When tar reaches the end of the first volume’s data, it will prompt:
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.shWhere 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}"Make it executable:
chmod +x next-volume.shA 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/htmlStep 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.2Typing 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*Step 4: Transfer volumes to the restore target (using scp, external drive, etc.)
scp /backups/website-backup.tar* admin@newserver:/restore/Step 5: Restore on the new server
cd /restore
tar --extract --multi-volume --file=website-backup.tarRespond to volume prompts the same way as during creation.
Step 6: Verify the restored data
diff -r /var/www/html /restore/var/www/htmlComparison: Single-Volume vs. Multi-Volume Archives
| Feature | Single-Volume Archive | Multi-Volume Archive |
|---|---|---|
| Fits on one media device | Yes (if small enough) | No — spans several devices/files |
| Command flag | none needed (default) | -M / --multi-volume |
| Handles files larger than one volume | N/A | Yes, files are split across volumes |
| Restore complexity | Simple, one command | Requires volume prompts or scripting |
| Common use case | Small backups, config files | Large backups, legacy tape systems, offline media transport |
| Automation friendliness | Very easy | Needs -F info-scripts for smooth automation |
Real-World Use Cases
- 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.
- 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.
- DVD/Blu-ray archival: Small businesses without cloud backup budgets sometimes still archive project files to optical media in multi-volume sets.
- 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=vol1to 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;
tarexpects 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-lengthvalue 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
sha256sumfor 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
-Finfo-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.vol1Conclusion
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.