• Less downtime
• Less stress
• Less loss of work

I have set my calendar to periodically take various types backups.

Yes, taking backups is hard, takes time and practice to do correctly, requires constant vigilance, and is an annoyance. But the stress I used to undergo every time the system breaks, is something I don’t want to experience ever again. As I grow older, the impact of this amount of stress on my health is noticeable.

Types of backups

I have different types of backups.

• Daily backups of my WordPress sites. These are done by cron, but I check on them weekly.
• Weekly backups of my git repositories to a Raspberry Pi and to an online droplet. I have a script that pushes all the master branches from all the repositories to a dedicated backup upstream.
• Monthly full disk backups of my dev machine.

This article is about the last type of backup. These protect me mostly against situations where something goes horribly wrong at the system level, or even in the case of a disk failure.

File systems often contain a lot of unnecessary clutter: caches, temporary files, old Docker images, unused Snap or Flatpak apps, and more. Backing up this bloat not only slows down the process, but also increases storage requirements and backup times unnecessarily.

In this article, I’ll walk you through my script that minimizes the amount of data that needs to be copied before taking a full disk backup.

The advantages of cleaning up caches before a backup are obvious:

• Smaller backups: Removing cache and orphaned files significantly reduces the size of the disk backup. Typically a few gigabytes are saved every time.
• Faster backup time: Especially with SSDs, where the more blocks are TRIMMED, the faster the disk copies and compresses.

Here’s a breakdown of what each step of my cleanup script does:

Time to take out the trash

First, install a tool that cleans the trash (if not already installed) and then clean the trash:

sudo apt install trash-cli -y && trash-empty -f

Clean up any dev projects

In my case, I have a lot of projects that are managed (and cleaned) with grunt or flutter. So I iterate over all of them and clean them. I also invoke the git garbage collector on my repositories:

gitdir="/home/alexg/workspace"
cd $gitdir

for p in grunt-project-1 grunt-project-2 grunt-project-3; do
    pushd "${gitdir}/${p}" && grunt clean && git gc --aggressive && popd
done

for p in flutter-project-1 flutter-project-2 flutter-project-3; do
    pushd "${gitdir}/${p}" && flutter clean && git gc --aggressive && popd
done

Clear package manager caches

npm cache clean --force
composer clear-cache
pip cache purge

These commands free up space by clearing the cache used by popular package managers: Node (npm), PHP (composer), and Python (pip).

Docker cleanup

docker system prune -a --volumes -f
docker image prune

Removes all unused Docker containers, networks, images, and volumes. This can recover gigabytes of space.

APT package manager cleanup

sudo apt autoremove -y
sudo apt autoclean -y
sudo apt clean

Cleans up unused packages and downloaded .deb files from system updates.

System journal cleanup

sudo journalctl --vacuum-time=2weeks

Truncates system logs to only retain entries from the last 2 weeks. Can save a few gigabytes.

Remove temporary and cache files

rm -rf /tmp/*
find ~ -type d -name "__pycache__" -exec rm -rf {} +
rm -rf ~/.cache/fontconfig/*
sudo fc-cache -rv
rm -rf ~/.cache/thumbnails/*
rm -rf ~/.cache/{mozilla/firefox,google-chrome,chromium}/*
find /var/tmp -type f -atime +10 -delete
sudo rm -rf /var/cache/*

These commands remove temporary files and caches from various locations including Python bytecode caches, font cache, browser caches, and more.

Remove unused applications

flatpak uninstall --unused
sudo snap list --all | awk '/disabled/{print $1, $3}' | while read snapname revision; do sudo snap remove "$snapname" --revision="$revision"; done

Removes unused Flatpak apps and old Snap package revisions.

Final user-level cleanup

rm -rf ~/.wine/drive_c/windows/temp/*
find ~/.cache -type f -atime +10 -delete
tracker reset --hard ; tracker daemon --stop

Cleans Wine temporary files, aged cache files, and resets GNOME’s Tracker file indexer.

TRIM your SSD

sudo fstrim / --verbose

Issues a TRIM command to the SSD, letting it know which blocks are no longer in use. When taking a full backup, these empty blocks will be read at lightning-fast speed, and will be compressed significantly with gzip since these are entire disk blocks of zeroes.

Zero out your mechanical disk

If you are using a mechanical disk you can skip this step, but it may be useful to zero out your empty space:

cat /dev/zero >~/zero ; rm zero

Full system backup to an external mechanical disk, using live USB

Once the system is cleaned, it’s time to create a full disk image. This should be done from a Live USB environment, with the system disk unmounted, to ensure a consistent snapshot. Here’s how I do it:

umount /dev/sdX
sudo dd if=/dev/sdX status=progress conv=sync,noerror | gzip > /mnt/backup/system-backup-$(date +%F).img.gz

• Replace sdX with your actual device (e.g., /dev/sda).
• status=progress: Show live progress during the backup.
• conv=sync,noerror: Ensures that read errors don’t abort the process and fills blocks with zeroes if needed.

Consistency is key

I have set a recurring reminder in my calendar to do this monthly.

I keep the last few backups and delete the oldest one every time.

Yes, it takes time, but it helps me sleep easier.

The post 🖴 Clean up all your Caches before taking a Full System Backup of your Linux machine appeared first on Alexandros Georgiou.

Shell here!

Apologies if you were expecting something WordPress-related. This article is NOT about WordPress. It’s about opening a shell here and now, in the directory of the file you’re currently editing.

Geany is the perfect IDE for any type of coding that is not your main development. I use it all the time for scripting, configuring, building, tooling, installing, uninstalling, and generally nerding out.

Geany, open sesame err, shell!

Go to Tools and then to Plugin Manager. Enable the File Browser. The file browser will appear as a new tab on the left-hand-side of the screen, along with Symbols and Documents. Now you can observe your file in its native habitat, the directory.

Now if you go to Edit and then select Plugin Preferences, you should see a field titled External Open Command which defaults to

nautilus "%d"

If you’re on Ubuntu, you’re probably using gnome-terminal as your terminal emulator. Change the line to

gnome-terminal --working-directory="%d"

Also click on Follow the path of the current file. It makes sure that the File Browser shows you the directory of the current file as you switch between editor tabs.

Now, when you right-click on a file, and choose Open Externally, you will get a new shell in the directory where that file resides.

But I miss nautilus!

If you’re missing the ability to open nautilus, just remember that once you have a terminal open, you can always issue this command:

nautilus .

(Note the dot, which is the current directory.)

If you know of a better/faster way that doesn’t involve writing a plugin, please comment. I’d like to know.

The post 🪔 Open terminal with shell here in Geany appeared first on Alexandros Georgiou.