For the complete documentation index, see llms.txt. This page is also available as Markdown.

Moving MikoPBX Data to a New Disk

Use this guide when the local MikoPBX storage is full or when the current data storage disk must be replaced. The storage contains call recordings, call history, system logs, additional modules, backups, and system caches. In a standard installation, the storage directory is mounted at /storage/usbdisk1.

This guide applies to MikoPBX installed on a virtual machine or a physical server. For Docker installations, move the host directory that is mounted into the container as /storage using the host operating system tools.

Important Notes

MikoPBX does not use a manually maintained /etc/fstab entry as the only source of truth. Disk information is stored in the MikoPBX configuration database, and when storage is connected, the system mounts the partition by UUID and rebuilds /etc/fstab.

After copying data, use the standard script to switch the storage disk:

/etc/rc/connect_storage

Do not run /sbin/freestorage as the first migration step from an SSH session. This script also stops the SSH server dropbear, so the remote session can be disconnected.

Requirements

  • root SSH access to MikoPBX;

Instructions for connecting via SSH are available here.

  • a new empty disk connected to the server;

  • a current backup of the configuration and important data;

  • enough free space on the current storage disk for the system to keep working during the copy;

  • a planned short telephony downtime while services are stopped and the PBX is rebooted.

Identify the Current and New Disks

Connect to MikoPBX over SSH and run the diagnostic commands:

Find:

  • the current storage partition mounted at /storage/usbdisk1;

  • the new disk with no mount point, no file system, and no important data.

Example: the current storage is on /dev/vdb1, and the new empty disk is /dev/vdc.

Check the new disk again:

If the disk has partitions, a file system, a UUID, a mount point, or you are not sure what the disk is used for, stop and confirm that it is really an empty disk.

Save a Local Copy of the Configuration Database

Before switching the disk, save a copy of the database and the current /etc/fstab:

This copy is not a replacement for a full backup, but it helps you quickly roll back the selected storage disk.

Stop Services That Write to Storage

Stop PBX workers and the main MikoPBX services:

Check that no processes still keep files open on the old storage:

If the command prints any processes, do not continue. Find the remaining service, stop it, and repeat the check.

Partition and Format the New Disk

Create a GPT partition table, one partition using the whole disk, and an ext4 file system:

Make sure the variables are populated:

Copy Data from the Old Storage

Mount the new partition to a temporary directory and copy the contents of the current /storage/usbdisk1:

Check the copy:

The object counts must match. If services are started before the migration is finished, the number of files can change because of logs and temporary files, so compare the counts while services are stopped.

Unmount the temporary mount point:

Connect the New Disk as MikoPBX Storage

Unmount the old storage partition from /storage/usbdisk1:

If you get target is busy, check which processes still use the mount point:

Stop the reported processes and repeat umount. If lsof and, when available, fuser show no holders but the partition is still busy, use the fallback option:

Run the standard storage connection script and pass the new disk name without /dev/:

The script should find the new partition with the mikopbx directory, save the UUID in the MikoPBX configuration, mount it at /storage/usbdisk1, and rebuild /etc/fstab.

Start Services

Return the services under monit control and restart the workers:

Check the state:

Check Persistent Mounting After Reboot

Reboot MikoPBX:

The SSH session may be disconnected. After MikoPBX boots, connect again and check:

In a correct state:

  • /storage/usbdisk1 is mounted from the new partition;

  • the UUID of the new partition is listed in /etc/fstab;

  • the m_Storage table points to the new disk;

  • /storage/usbdisk1/mikopbx and the call history database are accessible;

  • the main MikoPBX services have OK status in monit summary;

  • Asterisk responds to core show uptime.

Rollback

If the new disk is not connected correctly and the old disk has not been wiped, you can switch back to the old storage:

Replace vdb with the old disk name without /dev/.

If you need to restore the entire storage configuration record from the saved database copy:

Troubleshooting

/etc/rc/connect_storage says the disk is already mounted.

The old storage is still connected to /storage/usbdisk1. Stop the services that write to storage and run umount /storage/usbdisk1.

The new disk is not listed as a suitable disk.

Check lsblk -f. The disk must be visible to the system, must not be mounted elsewhere, and must be larger than 2 GB.

umount returns target is busy.

Use lsof +f -- /storage/usbdisk1 and, if available, fuser -vm /storage/usbdisk1. Stop the processes that keep files open. Use umount -l only after stopping services and checking that there are no active holders.

Storage is not mounted after reboot.

Compare the UUID in blkid, /etc/fstab, and m_Storage. Then connect storage again:

Services stay in Initializing or Waiting for a while.

This is normal for some monit checks immediately after boot. Wait 1-2 minutes and repeat:

Last updated

Was this helpful?