Free Your Root Partition by Moving /var/log to a tmpfs: A Step‑by‑Step Guide

 Posted on September 29, 2026  |  3 minutes  |  590 words  |  Robert Nilsson

Why Move /var/log to a tmpfs?

On most production boxes and home‑lab rigs the root file system is a single ext4 or btrfs partition that also holds /var/log. After a few months the logs can eat up gigabytes of space, especially on servers that churn out audit, kernel, or app logs. A full root partition can block package upgrades, kernel updates, or even prevent a boot if the filesystem gets remounted read‑only. Moving /var/log to a tmpfs frees the disk right away, keeps the logs in RAM, and cuts out the need to compress or rotate them manually.

The catch is volatility: the logs vanish on reboot and consume RAM that could be used by your applications. For most dev boxes, small web servers, or machines where you don’t need the logs after a reboot, that’s fine. If persistence is a must, you can back the tmpfs with a small encrypted log partition or ship the logs to a remote syslog.

Below is a practical, step‑by‑step walk‑through that covers:

  • safety checks and quick backups
  • sizing and mounting the tmpfs
  • moving existing logs without losing data
  • keeping systemd services happy
  • monitoring RAM usage and kernel tuning
  • troubleshooting common pitfalls
  • a quick look at the security side

1. Prerequisites and Safety Checks

  1. Root access – All commands need sudo or root.
  2. Enough RAM – The size you give the tmpfs must fit in memory (and swap).
  3. Backup – Even though logs are usually disposable, a quick copy protects against accidental data loss.
  4. Read‑only root – If your root is mounted read‑only (e.g., during a rescue session), remount it read‑write:
sudo mount -o remount,rw /
  1. Baseline usage – Get a snapshot before you touch anything:
df -h /
du -sh /var/log

2. Backing Up Existing Logs

Copy the current logs to a temporary location. This is the safety net if something goes sideways.

sudo mkdir -p /tmp/log_backup
sudo rsync -aAXv /var/log/ /tmp/log_backup/

The -aAXv flags preserve permissions, ACLs, and extended attributes. Verify the copy:

sudo diff -r /var/log/ /tmp/log_backup/

If diff shows nothing, you’re good to move on.

3. Choosing a Size for the tmpfs

A tmpfs is limited by RAM plus swap. The kernel’s default limit is 50 % of RAM, but you can override it. I usually start with 10–20 % of RAM for logs, unless you know you need more.

# Example: 512 MiB tmpfs on a 4 GiB system
TMPFS_SIZE=512M

If you have 8 GiB RAM and expect heavy logging, bump it to 1G.

4. Mounting /var/log as a tmpfs

You can mount a tmpfs via /etc/fstab or a dedicated systemd unit. The systemd way gives you finer control and plays nicely with the boot order.

4.1 Using /etc/fstab

Add this line to /etc/fstab:

tmpfs   /var/log   tmpfs   defaults,noatime,size=${TMPFS_SIZE},mode=0755   0   0
  • noatime reduces write traffic.
  • mode=0755 gives services write access.
  • size= caps the memory usage.

Mount it right away:

sudo mount -a

Check:

mount | grep /var/log

You should see:

tmpfs on /var/log type tmpfs (rw,noatime,size=512M,mode=0755)

4.2 Using a systemd Unit

Create /etc/systemd/system/tmpfs-var-log.mount:

[Unit]
Description=Mount /var/log as tmpfs
Before=local-fs.target
After=network.target

[Mount]
What=tmpfs
Where=/var/log
Type=tmpfs
Options=defaults,noatime,size=${TMPFS_SIZE},mode=0755

[Install]
WantedBy=local-fs.target

Enable and start it:

sudo systemctl enable --now tmpfs-var-log.mount

The systemd unit approach is preferable if you want the mount to be managed by systemd’s dependency graph and to survive early boot stages.

5. Moving Existing Logs to the New Mount

The tmpfs mount is now empty. Copy the old logs over, keeping timestamps and permissions:

sudo rsync -aAXv /tmp/log_backup/ /var/log/

Because /var/log is now a tmpfs, the copy writes to RAM. Verify:

linux  open-source 

See also