Kubuntu Focus: Big Data Management Guided Solution

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 stores big data on 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 to 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 MySQL Database
Move MariaDB Database
Move PostgreSQL Databases
Move Docker Containers
Move Other Big Data Files
Troubleshooting
Revisions
Disclaimer

Move big data to 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

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

# Stop the MySQL server sudo systemctl stop mysql.service; # Move data and logs sudo mv /var/lib/mysql /home/mysql; sudo mv /var/log/mysql /home/mysql-logs;

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

# Backup configuration cd /etc/mysql/mysql.conf.d; sudo cp mysqld.cnf mysqld.cnf.bak; # Enable and set 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 changes in 4 lines sudo -E meld mysqld.cnf.bak mysqld.cnf;

3. Adjust AppArmor config 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

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

# Stop the MariaDB server sudo systemctl stop mariadb.service; # Move data sudo mv /var/lib/mysql /home/mariadb; # Create log directories sudo mkdir -m 2750 /home/mariadb-logs sudo chown mysql:mysql /home/mariadb-logs;

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

# Backup the config cd /etc/mysql/mariadb.conf.d; sudo cp 50-server.cnf 50-server.cnf.bak; # Enable and set data dir sudo sed -i \ 's/#$datadir.*$/\1/; s?/var/lib/mysql?/home/mariadb?g;' \ 50-server.cnf; # Enable and set log dir sudo sed -i \ 's/#$log_error.*$/\1/; s?/var/log/mysql?/home/mariadb-logs?g;' \ 50-server.cnf; # Verify changes 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 config 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

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

# Stop the PostreSQL server sudo systemctl stop postgresql.service; # Move data and logs sudo mv /var/lib/postgresql /home/postgresql; sudo mv /var/log/postgresql /home/postgresql-logs;

2. Configure PostgreSQL to use the updated data directory.

# Backup the config 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;

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 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

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

# Stop Docker daemon sudo systemctl stop docker.socket; sudo systemctl stop docker.service; # Move data sudo mv /var/lib/docker /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 "Setting |${_cfg_file}|"; echo "${_line}" | sudo tee "${_cfg_file}" \n && _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

4. 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 appliable) 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.

2025-07-30 6684c321 First publication

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.