Your First Linux Backup: 7 Steps to Create and Check It

Magnifying glass inspecting files inside a transparent backup archive, illustrating Linux backup verification. Linux & Administration
Create your first Linux backup in seven practical steps. Include hidden files, inspect the archive, compare it with the source, and save a checksum before testing recovery.
Linux Backups · Lesson 02 / 03 · Hands-on

Make a backup you can actually inspect.

An archive on disk is a start. Knowing what went into it is better. In this lesson, you will create a small Linux backup, check that it includes a hidden file, compare it with the source and save a checksum for later.

The method: use GNU tar to archive a quiet directory, list its contents, compare it with unchanged source files, then record a SHA-256 checksum. These checks prepare you for a restore test; they do not replace one.

From a folder to an archive, then a closer inspection A pale glass folder sends three files into a mint archive box. A magnifying glass examines the archive. The image represents creating and inspecting a file backup.
A folder becomes an archive. Listing, comparison and a checksum give you different evidence about that copy. Restoring it is the next test.
01 / PREPARE

Start with a separate workspace

Use Bash on a Linux machine with GNU tar, gzip, GNU Coreutils and find. Ubuntu and Debian commonly provide these tools. This lab needs no sudo and uses only files you create. Run the steps in the same terminal; if any command reports an error, stop and resolve it before continuing.

BASH · CHECK THE TOOLS
command -v tar gzip sha256sum mktemp find
tar --version

Confirm that the version output identifies GNU tar and that every requested tool has a path. Then create a unique lab directory under your home folder:

BASH · CREATE THE WORKSPACE
backup_lab=$(mktemp -d "$HOME/sa-backup-lab.XXXXXX")
printf 'Lab directory: %s\n' "$backup_lab"
02 / MAKE THE SOURCE

Add a few files worth checking

Make two ordinary text files and one hidden file. The hidden file is deliberate: it gives you something easy to miss if you later replace a directory argument with a shell wildcard.

BASH · CREATE TRAINING DATA
mkdir "$backup_lab/source" "$backup_lab/archives"
mkdir "$backup_lab/source/notes"
printf 'A small backup practice folder.\n' > "$backup_lab/source/readme.txt"
printf 'Remember to test recovery.\n' > "$backup_lab/source/notes/todo.txt"
printf 'DEMO_MODE=yes\n' > "$backup_lab/source/.demo-settings"

These are disposable examples, not real application data or credentials. Leave them unchanged until the comparison in Step 06.

03 / CHECK THE SCOPE

Know what should go into the archive

BASH · INSPECT THE SOURCE
find "$backup_lab/source" -type f -print

You should see paths ending in readme.txt, notes/todo.txt and .demo-settings. Their order may differ. This small inventory is your reference when you inspect the archive.

Why not just back up source/*?

In Bash’s default configuration, * does not match names beginning with a dot. Passing the directory itself to tar lets tar walk it, including hidden entries. In the next command, --directory selects the source folder and . selects that directory’s contents.

04 / CREATE THE COPY

Keep the archive outside the source

The source and archive directories are siblings. This keeps the output file out of the directory tar is reading.

BASH · CREATE A COMPRESSED ARCHIVE
tar --create --gzip \
  --file="$backup_lab/archives/files.tar.gz" \
  --directory="$backup_lab/source" . \
  && printf 'Archive created.\n'

--create builds the archive, --gzip compresses it, and --file names the output. GNU tar often prints nothing on success here; the final message appears only if tar exits successfully.

What if tar says a file changed while being read?

The source may not have stayed still during the copy. Investigate instead of treating the archive as a clean recovery point. This lab uses quiet text files; a live database needs its own documented backup procedure.

05 / OPEN THE INVENTORY

Check the names before trusting the file

BASH · LIST, WITHOUT EXTRACTING
tar --list --gzip --file="$backup_lab/archives/files.tar.gz"

The listing should include these entries, although the order can vary:

./
./readme.txt
./notes/
./notes/todo.txt
./.demo-settings

A plausible file size would not tell you that the hidden file is missing. A listing can. It still does not prove that the saved contents match the source.

06 / COMPARE

Check the copy against the quiet source

GNU tar can compare archive members with their matching files on disk. Use the same source directory as before:

BASH · COMPARE ARCHIVED MEMBERS
tar --compare --gzip \
  --file="$backup_lab/archives/files.tar.gz" \
  --directory="$backup_lab/source" \
  && printf 'Archived members match the source.\n'

With the unchanged lab files, expect the final message and no difference reports. GNU tar checks member contents and metadata such as size, mode, ownership and modification time. Reported differences or errors need attention.

What this comparison does not catch

It checks members already in the archive. A new source file that was never archived is not an archive member to compare. That is why the inventory in Step 03 and listing in Step 05 matter too. The comparison also does not start an application or prove a future restore will work.

07 / RECORD A FINGERPRINT

Save a checksum before moving the archive

Record a SHA-256 checksum of the archive, then check it immediately. The parentheses run this block in a subshell, so your terminal keeps its original working directory.

BASH · WRITE AND CHECK THE CHECKSUM
(
  cd "$backup_lab/archives" &&
  sha256sum files.tar.gz > files.tar.gz.sha256 &&
  sha256sum --check files.tar.gz.sha256
)
files.tar.gz: OK

That result means the archive matches the checksum just recorded. After copying the archive and checksum file elsewhere, run the check from their destination directory. Keep the original checksum: regenerating it from a damaged copy would simply record that damaged copy.

READ THE EVIDENCE

What you have checked so far

Check What it tells you
Archive listing The expected paths appear in the archive.
GNU tar comparison The archived members match the unchanged source within the properties checked.
SHA-256 check The archive’s bytes match the recorded checksum.
Restore test Still to do: extract into a separate directory and inspect the recovered files.

Keep the lab directory, its source files, the archive and the checksum for Lesson 03. Nothing needs to be scheduled yet. First, make sure you can get the files back.

If a check fails

Missing path: revisit the source selection and archive command. Comparison difference: check whether you edited the source after archiving. Checksum failure: confirm that you are checking the intended archive against its original checksum. Preserve the failed copy while you investigate rather than overwriting it immediately.

Official references

Servers Academy Editorial Team · Linux Backups: Create, Schedule, Restore · Lesson 02

Rate article
Servers Academy
Add a comment