Learn Linux - Symbolic Links, Archiving & Compression

#Introduction

After episode 6 where we covered text processing — grep, sort, awk, sed — in this episode we'll discuss three different but interrelated topics that are equally important in daily operations: symbolic links, archiving, and compression.

Why is this topic important? Imagine you need to share a configuration used by two applications at once, or send 5 GB of logs to a colleague, or make regular backups of the /etc directory. Without understanding links, you'll copy files over and over and modify them in many places. Without understanding tar and compression, you'll store and transfer data wastefully — and worse, without the right format, archives can be corrupted or wrongly structured when extracted.

In this episode we'll cover: first, hard links vs symlinks along with the inode concept; second, tar as the universal archive format; third, a comparison of gzip, bzip2, xz, and zip; fourth, a safe and verified /etc backup case study.

#Main Discussion

#Hard Link vs Symlink: Understanding Inodes

Before distinguishing links, we need to understand the inode concept. In Linux, every file is actually two things: data (the file's contents) and metadata (the inode — containing size, owner, permissions, data location, and a reference counter). The file name is just an entry in a directory pointing to an inode. The file name isn't the file itself — it's the entryway.

#Hard Link (`ln`)

A hard link is an additional name pointing to the same inode. Two names, one inode, one piece of data:

Creating a hard link

echo "isi dokumen" > dokumen.txt
ln dokumen.txt salinan.txt
ls -l dokumen.txt salinan.txt

Note: both have the same inode number and the same size. Changing the contents through either name will be visible from the other, because both refer to the same data. Delete one of them? The data stays alive as long as at least one name remains — the inode's reference counter drops but doesn't reach zero.

The important limit of hard links: they can't cross filesystems. Two different directories on the same mount point can be linked, but /home and /var mounted as separate filesystems — impossible, because inodes are local to each filesystem.

#Symbolic Link (`ln -s`)

A symbolic link (symlink) is a small file containing a path to another file. It doesn't point to the target's inode, but rather "points to a name". If the target is deleted, the symlink becomes broken — but the symlink itself still exists:

Creating a symlink

ln -s dokumen.txt tautan.txt
ls -l tautan.txt
cat tautan.txt
rm dokumen.txt
ls -l tautan.txt

The ls -l line shows the arrow tautan.txt -> dokumen.txt — the hallmark of a symlink. After dokumen.txt is deleted, tautan.txt becomes a dangling link pointing to a file that doesn't exist.

Aspect	Hard Link	Symlink
Points to	The same inode	The target's name/path
`ls -l` display	Like an ordinary file	`name -> target`
Can cross filesystems	No	Yes
Can point to directories	No	Yes
When the target is deleted	Data remains (other names live on)	Link becomes broken
Extra size	None	Stores the path string

Tip

The rule of thumb for choosing: symlinks for almost all needs — they can point across filesystems, can point to directories, and are introspective (clear from ls -l where they point). Hard links are only useful when you want several names referring to the same data on the same filesystem, for example versions of a binary stored once. Symlinks are the safe default; hard links are a specialized tool.

#`tar`: The Universal Archive Format

tar (tape archive) was born in the era of magnetic tape, but today it's the standard format for packaging many files into one. tar's strength over plain zip: it doesn't modify the original files (no compression by default), and compression is separated as an optional layer. Let's break down the core options using the czvf mnemonic:

Letter	Option	Meaning
`c`	`--create`	Create a new archive
`x`	`--extract`	Extract an archive
`t`	`--list`	List the contents without extracting
`z`	gzip	Compress with gzip
`v`	`--verbose`	Show each file being processed
`f`	`--file`	Specify the archive file name

Creating a compressed archive

tar -czvf backup-etc.tar.gz /etc

The line above creates the archive backup-etc.tar.gz containing the entire /etc with gzip compression, while printing each file being packaged (v). To extract:

Extracting an archive

tar -xzvf backup-etc.tar.gz

To inspect an archive's contents without extracting — a skill that saves you from overwriting the wrong files:

Viewing archive contents

tar -tzvf backup-etc.tar.gz

t replaces c or x, and shows the file list along with metadata — exactly like ls -l, but inside the archive. Always inspect with tar -tzvf before extracting, especially archives from sources you don't fully trust.

Important

The difference between absolute vs relative paths is very decisive. tar -czvf backup.tar.gz /etc stores entries with the path etc/... (leading slash stripped), so when extracted the files go into the working directory — safe. However, tar -czvf backup.tar.gz /etc/passwd will store etc/passwd and extract it relatively too. Beware of archives created with -P (preserve path): they extract exactly at the absolute location and can overwrite system files. Always check the contents with tar -tzvf before extracting unfamiliar archives.

#Choosing a Compression Tool: gzip, bzip2, xz, zip

tar only packages files; compression is a separate layer. There are several algorithms with different trade-offs — speed vs ratio:

Tool	Extension	Speed	Ratio	When to Use
`gzip`	`.gz`	Fast	Medium	Default standard, available almost everywhere
`bzip2`	`.bz2`	Medium	Smaller	Large archives rarely accessed
`xz`	`.xz`	Slow	Smallest	Software distribution, long-term archive backups
`zip`	`.zip`	Fast	Medium	Interop with Windows / file sharing

All of them can be used directly through tar by swapping the letter: -czf (gzip), -cjf (bzip2), -cJf (xz). As a rough illustration, let's compare the compressed sizes of the same log file:

Compression size comparison

-rw-r--r-- 1 dev dev   10485760 Agu  2 09:00 app.log
-rw-r--r-- 1 dev dev    1234567 Agu  2 09:01 app.log.gz
-rw-r--r-- 1 dev dev    1123456 Agu  2 09:01 app.log.bz2
-rw-r--r-- 1 dev dev     987654 Agu  2 09:01 app.log.xz

The ~10 MB original shrinks to ~1.2 MB with gzip, ~1.1 MB with bzip2, and ~0.9 MB with xz. The difference is real at scale, but remember: compression and decompression time must also be factored in. For logs that must be opened quickly and repeatedly, gzip is often the most balanced choice.

Individual compression

gzip app.log
bzip2 app.log
xz app.log
unzip backup.zip

Each tool above replaces the original file with its compressed version (except zip, which packages many files into one archive). Their counterparts: gunzip, bunzip2, unxz to restore.

Note

Compression is a lossless process — the contents of a compressed and decompressed file are identical. This differs from image/video compression (lossy) which sacrifices quality. That's why compressing logs or configuration is always safe for data integrity; all you lose is disk space and CPU time.

#Testing Archive Integrity and Setting Compression Levels

Creating an archive isn't enough; you must be sure the archive is intact. For gzip archives, there's a built-in test that doesn't extract the contents:

gzip integrity test

gzip -t backup-etc.tar.gz

gzip -t (test) checks the compressed file's structure and flags corruption without extracting its contents. Complement it with du to make sure the backup size is reasonable:

Check source and result sizes

du -sh /etc
du -sh /backup/etc-20260802-0930.tar.gz

Comparing these two numbers gives you a sense of the compression ratio — and an early signal of problems: a backup that's far smaller than expected could mean many files failed to be read, while one that doesn't shrink at all signals already-compressed data (like binary databases) or a method error.

Additionally, gzip supports compression levels with clear speed trade-offs:

gzip option	Effect
`-1` (fast)	Fastest compression, largest result
`-6` (default)	Balance of speed and size
`-9` (best)	Smallest result, slowest
`-k` (keep)	Keep the original file after compression
`-t` (test)	Test integrity without extracting

Tip

Choose the compression level based on the archive's lifecycle, not just the final size. Routine nightly backups should use default gzip or -1 so they finish quickly; distribution archives kept long-term are worth paying for with slow xz time to get the smallest size. Remember: time is also a cost — and an archive that fails to complete on time costs more than a few hundred extra MB.

#Case Study: A Safe `/etc` Backup Routine

Let's chain everything in a scenario you'll definitely face: routine /etc backups — the directory containing all system configuration. Configuration disasters (deleted files, bad edits, corruption) happen quickly; a good backup saves you from redoing hours of manual configuration.

Step 1 — create an archive with a timestamp so every backup is unique:

Backup with timestamp

tar -czvf /backup/etc-$(date +%Y%m%d-%H%M).tar.gz /etc

$(date +%Y%m%d-%H%M) produces a string like 20260802-0930, so the file name is always unique per execution time.

Step 2 — verify the archive after creating it. A backup that can't be verified isn't a backup — it's just an assumption:

Verify the archive contents

tar -tzvf /backup/etc-20260802-0930.tar.gz | head -5

Verification output

drwxr-xr-x root/root       0 2026-08-02 09:30 etc/
-rw-r--r-- root/root     512 2026-08-02 09:30 etc/hostname
-rw-r--r-- root/root    1024 2026-08-02 09:30 etc/hosts
-rw-r--r-- root/root    3320 2026-08-02 09:30 etc/passwd
-rw-r--r-- root/root    1256 2026-08-02 09:30 etc/group

Step 3 — to restore, extract into a temporary directory first, then copy what's needed — don't extract directly over /etc:

Extract into a temporary directory

mkdir -p /restore && tar -xzvf /backup/etc-20260802-0930.tar.gz -C /restore

The -C (change directory) option extracts into /restore so it appears as /restore/etc/.... From there you can compare and choose which files truly need restoring — far safer than overwriting a running configuration.

Caution

Remember the two tar traps that often trip up new users: (1) an archive created with an absolute path (tar -czf a.tar.gz /etc/passwd) stores the entry etc/passwd, not passwd — make sure you know where its contents will extract; (2) symlinks inside an archive are still extracted as symlinks, and if their targets aren't archived too, the extraction result is a broken link. Always test a restore in a temporary directory before returning files to their original location.

#Common Pitfalls

Mistake	Symptom	Solution
`ln` without `-s` for general needs	Changes not visible through all "names" and can't cross filesystems	Use `ln -s` as the default
Symlink broken after target moved/deleted	`No such file or directory` even though `ls` shows the link	Fix by recreating the symlink pointing to the new path
Hard link across filesystems	Error `Invalid cross-device link`	Use a symlink or copy the file
Extracting an archive without `tar -tzvf` first	Files overwritten at unexpected locations	Always check contents & paths first
Backup without verification	Corruption discovered too late	Verify with `tar -tzvf` immediately after creating
Unknowingly using `-P` or absolute paths	Extraction overwrites system files	Avoid `-P`; use relative paths + `-C` for restore
Choosing `xz` for frequently accessed files	Slow decompression on every access	Choose gzip for access balance

#Conclusion

In this episode 7, we've covered: the fundamental difference between hard links and symlinks rooted in the inode concept; tar as the universal archive format with the czvf mnemonic; the comparison of gzip, bzip2, xz, and zip along with the speed vs ratio trade-offs; and a safe /etc backup routine with timestamps, verification, and restore into a temporary directory.

Key takeaways:

The inode is the real file; the name is the entryway — hard links point to inodes, symlinks point to names.
Symlinks as the default; hard links as a specialized tool for cases impossible across filesystems.
tar -czvf to create, -xzvf to extract, -tzvf to verify — memorize the mnemonic.
Always verify after a backup — a backup without verification is just a hope.
Restore into a temporary directory (-C) before overwriting a running configuration.

This ability to archive and secure data will be the foundation when you manage many users on a single server. In the next episode 8, we'll discuss User & Group Management — the multi-user and superuser concepts, creating and managing accounts with useradd, usermod, passwd, understanding the contents of /etc/passwd, /etc/shadow, and /etc/group, through to building a locked-down, secure deploy user. Stay motivated, because user management is the gateway to the permissions management we'll cover afterward!