Move an Oversized Folder to Block Storage with a Symlink
A 14G backup folder filled the root disk. The move-to-block-storage-with-symlink pattern relieves disk pressure without deleting backup data.
TL;DR
When the root disk hit 95 percent, the culprit was a 14GB WordPress plugin backup folder. Instead of deleting it, the fix moved the folder intact to block storage and left a symlink at the old path, dropping usage to 44 percent. Verify file counts, use absolute paths, and persist the mount in fstab to avoid dangling links.
The monitoring dashboard showed root disk usage at 95 percent. An audit with du found the largest contributor: an image-backup folder belonging to a WordPress image-optimization plugin, 14 gigabytes in size. The resolution did not stop at cleanup. The folder was moved intact to block storage, and the root disk dropped back to 44 percent.
The first reflex when a disk fills up is usually to delete the largest folder. For a backup folder that is the wrong move. Its contents are still needed for recovery, and the plugin's official documentation warns to never rely solely on the plugin's internal backups [6]. The right decision is to move the data, not delete it. The same pattern applies to any folder that grows out of proportion: database dumps, log archives, or media uploads.
The mechanism that makes this approach legitimate lives at the filesystem level. A symbolic link is a file whose contents are the pathname string of another file, and a symlink may point to a directory and cross filesystem boundaries [2]. The Unix directory tree can also span multiple devices; the mount command is what attaches a filesystem from another device into the single tree [4]. These two facts are what let the application keep reading the old path while the data physically lives on a separate volume.
Before deciding to move anything, make sure the oversized folder is actually safe to move. Image backups and log archives are safe to move while the server runs; files being written by another process are not. The lsof command checks for processes still holding files inside the folder while the move is in progress.
Audit and Volume Preparation
The first step is still the audit. Record the total size and file count of the source folder as a baseline, then make sure the block storage volume is available and mounted. The system tolerates a mount point at any location because the whole directory tree can span several devices [4].
Moving with rsync and Verifying
The command shape looks like this, with example paths to adjust:
du -sh /var/www/html/wp-content/ewww
df -h /
rsync -a /var/www/html/wp-content/ewww/ /mnt/blockstorage/ewww/
find /mnt/blockstorage/ewww/ -type f | wc -l
mv /var/www/html/wp-content/ewww /var/www/html/wp-content/ewww.old
ln -s /mnt/blockstorage/ewww /var/www/html/wp-content/ewwwMove the folder contents with rsync -a. The archive option copies links, devices, owners, groups, and permissions intact [1]. The rsync quick check only transfers files whose size or modification time changed, which makes re-running an interrupted move cheap [1].
Once the copy finishes, compare the total size and file count at the destination against the baseline. This verification is mandatory before the source folder is touched. Do not delete the source folder before the numbers match; in this incident the source folder was not deleted, only swapped out.
File ownership matters too. The rsync archive option already carries the original owner and group, so no extra chown adjustment is needed when the move runs as the same user that owns the old files. When it runs as a different user, fix ownership at the new location before swapping the folders so the application does not lose write access.
Swapping with a Symlink
Once verification passes, rename the original folder, then create the link to the new location with ln -s. Absolute paths are safer for cross-volume links because a relative link is interpreted relative to the link's parent directory [3].
Test that the application reads and writes through the link. In this incident the WordPress application kept reading the wp-content/ewww path, unaware its contents now lived on block storage.
Persistence and the Dangling-Link Trap
The new volume must mount automatically at boot. Configure it through /etc/fstab or a systemd .mount unit; mount units are named after the mount point directory they control [5]. Without this, a rebooted server comes back with a symlink pointing at a path that does not exist, known as a dangling link [2]. The application reads the old path and fails because the link's target is not mounted.
The move-to-volume-plus-symlink pattern solves a full disk without sacrificing backup data. Three things carry it: verify before swapping, absolute paths for cross-volume links, and mount persistence tested with a reboot.