Choose a clear backup scope
This example backs up a directory named project inside your home directory on Ubuntu 24.04 LTS or AlmaLinux 9. Replace project consistently if your folder has another name. Run as the user who owns the files. Confirm that the source exists and that the destination filesystem has enough free space before proceeding.
A file archive is suitable for documents, static website files, and configuration copies. It does not automatically produce a consistent backup of a database that is being written to. Use the database's own export or backup procedure for that data, and avoid modifying the project during this example.
ls -ld "$HOME/project"
du -sh "$HOME/project"
df -h "$HOME"Create a uniquely named archive
Set a restrictive permission mask so the backup directory and archive are private to your account. Keep backups outside the source directory to avoid including an archive inside itself. The uniquely generated subdirectory also prevents a repeat run from replacing your previous backup.
The tar command changes to your home directory before adding project. This stores a relative project path, making the archive easier to inspect and restore into a different location. Keep this shell session open because subsequent commands use the variables created here.
umask 077
mkdir -p "$HOME/backups"
backup_dir=$(mktemp -d "$HOME/backups/project-XXXXXXXX")
backup_archive="$backup_dir/project.tar.gz"
tar -czf "$backup_archive" -C "$HOME" project
printf '%s\n' "$backup_archive"Verify that the archive is readable
Do not assume that a file's existence means the backup succeeded. Read tar's output and check for errors such as unreadable files or files changing during the archive operation. List the archive's members and verify that the paths you expected are present.
Test the compressed stream and generate a checksum. The checksum can help you detect corruption after transferring the archive; it does not establish that the archived application data was complete or internally consistent.
tar -tzf "$backup_archive"
gzip -t "$backup_archive"
sha256sum "$backup_archive"Restore into a separate directory
Create a new empty directory under /tmp and extract your own archive there as your normal user. This leaves the original project untouched. Never test a restore directly over the live files: matching paths can otherwise replace existing content.
Compare the extracted directory with the original and open a few important files. With the source unchanged, diff should produce no output and return success. If differences appear, investigate them before trusting the backup. The temporary copy remains available for inspection.
restore_dir=$(mktemp -d /tmp/glws-restore-XXXXXXXX)
tar -xzf "$backup_archive" -C "$restore_dir"
diff -qr "$HOME/project" "$restore_dir/project"
printf 'Restore directory: %s\n' "$restore_dir"project/
project/subdir/
project/subdir/check.txt
Restore directory: /tmp/glws-restore-26L16V2I
Archive integrity and restored contents verifiedKeep an independent copy
A backup stored on the same VPS can be lost with that VPS. Copy the verified archive to a separate system or backup destination and protect it appropriately if it contains secrets. Keep multiple dated copies and repeat the restore test regularly. Record what was backed up and where the recovery copy lives.
Official documentation
These upstream references provide more detail on the commands and workflows in this guide.