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.
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.
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:
backup_lab=$(mktemp -d "$HOME/sa-backup-lab.XXXXXX")
printf 'Lab directory: %s\n' "$backup_lab"
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.
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.
Know what should go into the archive
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.
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.
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.
Check the names before trusting the file
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.
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:
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.
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.
(
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.
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.








