Maintain Root Filesystem Space

Big Data Management

Choose the best disk location for your big data. This helps reduce snapshot size, eases management, and improves performance.

Database servers, container platforms, and similar software often store big data in the root filesystem, under the /var directory. In Kubuntu 24.04, the root filesystem is BTRFS to facilitate System Rollback. To minimize snapshot size and improve performance, we recommend storing this big data in a separate filesystem or volume.

Besides other benefits, moving this data will prevent it from being reverted when you roll back to a prior snapshot. This is almost always the desired behavior for persistent data.

Move big data to keep snapshots small.

Move big data to keep snapshots small.

Please read the disclaimer before proceeding. We review and update guided solutions regularly. If you have suggestions or requests, please write support@kfocus.org.

Move MySQL Database

MySQL is a popular database engine from Oracle. It uses AppArmor sandboxing for security, so moving it to a different location requires configuration adjustments.

1. Stop the MySQL server to prevent data corruption. Then move the data and logs.

for _idx in 1; do # Check the destination if [ -d /home/mysql ] || [ -d /home/mysql-logs ]; then echo 'ABORT: Destination dirs already exist!'; echo 'Please inspect them before proceeding'; break; fi # Stop the MySQL server sudo systemctl stop mysql.service # Move the data and logs sudo mv /var/lib/mysql /home/mysql; sudo mv /var/log/mysql /home/mysql-logs; # Link back directories cd /var/lib && sudo ln -s /home/mysql ./mysql; cd /var/log && sudo ln -s /home/mysql-logs ./mysql; done

Inspect the moved data and logs. The links should point to the destination dirs, and destination dirs should contain files.

# Show the links to the destination dirs ls -ald /var/lib/mysql /var/log/mysql; # Show the destination dirs content sudo ls /home/mysql /home/mysql-logs;

2. Configure MySQL to use the updated data and log directories.

# Back up the config file cd /etc/mysql/mysql.conf.d; sudo cp mysqld.cnf mysqld.cnf.bak; # Enable and set the data dir sudo sed -i \ 's/# \(datadir.*\)/\1/; s?/var/lib/mysql?/home/mysql?g;' \ mysqld.cnf; # Set log dir sudo sed -i \ 's?/var/log/mysql?/home/mysql-logs?g;' \ mysqld.cnf; # Verify the changes in 4 lines sudo -E meld mysqld.cnf.bak mysqld.cnf;

3. Adjust AppArmor configuration so the MySQL server can access the data.

echo ' # Allow dirs in /home alias /var/lib/mysql/ -> /home/mysql/, alias /var/log/mysql/ -> /home/mysql-logs/, ' | sudo tee -a /etc/apparmor.d/tunables/alias; sudo systemctl restart apparmor.service;

4. Restart the MySQL server.

sudo systemctl start mysql.service;

5. Delete large snapshots (such as those containing the old data directory) to free up space. See these steps for guidance.

Move MariaDB Database

MariaDB is a fork of MySQL. It uses systemd sandboxing for security, so moving it to a different location requires configuration adjustments. Because it is meant to be a drop-in replacement for MySQL, many of the steps and some of the directories are the same as MySQL.

1. Stop the MariaDB server to prevent data corruption, then move the data.

for _idx in 1; do # Check the destination if [ -d /home/mariadb ] || [ -d /home/mariadb-logs ]; then echo 'ABORT: Destination dirs already exist!'; echo 'Please inspect them before proceeding'; break; fi # Stop the MariaDB server sudo systemctl stop mariadb.service; # Move the data sudo mv /var/lib/mysql /home/mariadb; # Mariadb logs to the journal by default # Create log directory sudo mkdir -m 2750 /home/mariadb-logs sudo chown mysql:mysql /home/mariadb-logs; # Link back directories cd /var/lib && sudo ln -s /home/mariadb ./mysql; cd /var/log && sudo ln -s /home/mariadb-logs ./mysql; done

Inspect the moved data and logs. The links should point to the destination dirs, and the destination dirs should contain files.

# Show the links to the destination dirs ls -ald /var/lib/mysql /var/log/mysql; # Show the destination dirs content sudo ls /home/mariadb /home/mariadb-logs;

2. Configure the MariaDB server to use the updated data and log directories.

# Back up the config file cd /etc/mysql/mariadb.conf.d; sudo cp 50-server.cnf 50-server.cnf.bak; # Enable and set the data dir sudo sed -i \ 's/#\(datadir.*\)/\1/; s?/var/lib/mysql?/home/mariadb?g;' \ 50-server.cnf; # Enable and set the log dir sudo sed -i \ 's/#\(log_error.*\)/\1/; s?/var/log/mysql?/home/mariadb-logs?g;' \ 50-server.cnf; # Verify the changes in 2 lines sudo -E meld 50-server.cnf.bak 50-server.cnf;

3. You may skip this step if you are not using the /home/ directory; otherwise, adjust the systemd configuration so MariaDB server can access the data.

# Create service setting override _dir='/etc/systemd/system/mariadb.service.d'; sudo mkdir -p "${_dir}"; echo '[Service] ProtectHome=false ' | sudo tee "${_dir}/override.conf"; # Load changes sudo systemctl daemon-reload

4. Restart the MariaDB server.

sudo systemctl start mariadb.service;

5. Delete large snapshots (such as those containing the old data directory) to free up space. See these steps for guidance.

Move PostgreSQL Databases

PostgreSQL is a popular community-developed relational database application. In Ubuntu, PostgreSQL is not sandboxed.

1. Stop the PostgreSQL server to prevent data corruption, then move the data.

for _idx in 1; do # Check the destination if [ -d /home/postgresql ] \ || [ -d /home/postgresql-logs ]; then echo 'ABORT: Destination dirs already exist!'; echo 'Please inspect them before proceeding'; break; fi # Stop the PostreSQL server sudo systemctl stop postgresql.service; # Move the data and logs sudo mv /var/lib/postgresql /home/postgresql; sudo mv /var/log/postgresql /home/postgresql-logs; # Link back directories cd /var/lib; sudo ln -s /home/postgresql ./postgresql; cd /var/log; sudo ln -s /home/postgresql-logs ./postgresql; done

Inspect the moved data and logs. The links should point to the destination dirs, and the destination dirs should contain files.

# Show the links to the destination dirs ls -ald /var/lib/postgresql /var/log/postgresql; # Show the destination dirs content sudo ls /home/postgresql /home/postgresql-logs;

2. Configure PostgreSQL to use the updated data directory.

# Back up the config file cd /etc/postgresql/16/main; sudo cp postgresql.conf postgresql.conf.bak; # Set data directory sudo sed -i \ 's?/var/lib/postgresql?/home/postgresql?g;' \ postgresql.conf; # Verify the changes in 2 lines sudo -E meld postgresql.conf.bak postgresql.conf;

3. Configure PostgreSQL to use the updated log directory.

# Enable log destination cd /etc/postgresql/16/main; sudo sed -i \ 's/#\(log_destination.*\)/\1/;' \ postgresql.conf; # Enable log collector sudo sed -i \ 's/#logging_collector = off\(.*\)/logging_collector = on\1/;' \ postgresql.conf; # Set log directory sudo sed -i \ 's?#log_directory = '\''log'\''\(.*\)?log_directory = '\''/home/postgresql-logs'\''\1?;' \ postgresql.conf; # Verify the changes sudo -E meld postgresql.conf.bak postgresql.conf

4. Change the home directory of the postgres user, then restart the PostgreSQL server.

# Change PostgreSQL home sudo usermod -d /home/postgresql postgres; # Restart PostgreSQL server sudo systemctl start postgresql.service;

5. Delete large snapshots (such as those containing the old data directory) to free up space. See these steps for guidance.

Move Docker Containers

Docker is a container engine for running applications in isolated namespaces. In Ubuntu, Docker is not sandboxed, and it stores all its data in a single directory.

1. Stop the Docker daemon to prevent data corruption, then move the data.

for _idx in 1; do # Check the destination if [ -d /home/docker ]; then echo 'ABORT: Destination dir already exists!'; echo 'Please inspect before proceeding'; break; fi # Stop the Docker daemon sudo systemctl stop docker.socket; sudo systemctl stop docker.service; # Move the data sudo mv /var/lib/docker /home/docker; # Link back directories cd /var/lib; sudo ln -s /home/docker ./docker; done

Inspect the moved data. The link should point to the destination dir, and the destination dir should contain files.

# Show the links to the destination dir ls -ald /var/lib/docker; # Show the destination dir contents sudo ls /home/docker;

2. Configure Docker to use a different data directory.

_cfg_file='/etc/docker/daemon.json'; _line='{ "data-root": "/home/docker" }'; _is_set='n'; if [ ! -f "${_cfg_file}" ]; then echo "Creating |${_cfg_file}|"; echo "${_line}" | sudo tee "${_cfg_file}" && _is_set='y'; elif grep -q "${_line}" "${_cfg_file}"; then _is_set='y'; fi if [ "${_is_set}" = 'y' ]; then echo 'OK: data-root looks configured.'; else echo "WARN: ${_cfg_file} exists. Please edit this file to contain |${_line}|"; fi

3. Restart the Docker daemon.

sudo systemctl start docker.socket; sudo systemctl start docker.service;

5. Delete large snapshots (such as those containing the old data directory) to free up space. See these steps for guidance.

Move Other Big Data Files

Most applications that manage big data can have their data moved by relocating it to another directory, then changing a configuration file to point to it. If this is not possible, you can usually symlink the new data location to the old location.

1. Ensure the application's service is stopped. This is required to prevent data corruption.

sudo systemctl stop myapp.service;

2. Move the application's data directory (and log directory, if applicable) to the desired alternate location.

sudo mv /var/lib/myapp /home/myapp; sudo mv /var/log/myapp /home/myapp-logs;

3. Symlink the new data and log directories back to the original locations.

sudo ln -s /home/myapp /var/lib/myapp; sudo ln -s /home/myapp-logs /var/log/myapp;

4. Check for AppArmor sandboxing. You may need to tell AppArmor that the new data location is an alias to the old location to allow access.

# Find AppArmor config for the server. cd /etc/apparmor.d; find | grep myapp; # If there is an AppArmor policy for the server, view it. kate /etc/apparmor.d/usr.bin.myapp; # If the configuration limits accessible directories, extend it. echo ' # Allow myapp from /home alias /var/lib/myapp/ -> /home/myapp/, alias /var/log/myapp/ -> /home/myapp-logs/, ' | sudo tee -a /etc/apparmor.d/tunables/alias; sudo systemctl restart apparmor.service;

5. Check for systemd sandboxing. Several systemd configuration options may limit the access an application has to the rest of the system. In particular, ProtectHome may prevent an application from accessing files under the /home directory.

# Check for home directory protection. if grep -q '^\s*ProtectHome\s*=\s*true' \ /usr/lib/systemd/system/myapp.service; then echo 'Home directory protection found.'; fi # If home protection is found, disable it. sudo systemctl edit myapp.service; # Type the following contents: # # [Service] # ProtectHome=false # # You can add other systemd configuration overrides here as well. # Save the file, then exit.

6. Restart the application.

sudo systemctl start myapp.service;

7. If the service fails to start, use systemctl and journalctl to see logs from the service. This data can oftentimes be used in web searches to find a fix.

# View service status to see recent logs sudo systemctl status myapp.service; # View more detailed logs from the service sudo journalctl -u myapp.service;

8. Delete large snapshots (such as those containing the old data directory) to free up space. See these steps for guidance.

Troubleshooting

Q: Disk space on the root filesystem isn't freed up after moving big data directories. How do I reclaim the space?

A: If a snapshot was created while big data files were present on the root filesystem, it will contain a copy of those files. Deleting the snapshots using the System Rollback Dashboard will fix this. You can click [ Show Snapshot Sizes ] in the Dashboard to identify and delete snapshots that are taking up space. After deleting snapshots, a reboot can open up more file space because it clears open file handles.

To open up more space, you can use [ Free Up Disk Space ] > [ Quick Clean ] which will optimize disk usage. Finally, one may erase all snapshots and optimize the disk using [ Free Up Disk Space ] > [ Deep Clean ].

Revisions

This is a partial revision history. See the git repository for all entries.

Disclaimer

We try hard to provide a useful solution validated by professionals. However, we cannot anticipate every situation, and therefore cannot guarantee this procedure will work for your needs. Always backup your data and test the solution to determine the correct procedure for you.

THIS SOLUTION IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOLUTION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

HAVE QUESTIONS?Call 844-536-2871 or write
TellMeMore@kfocus.org   |  GET FOCUS MERCH