SUMMARY
If there is not enough disk space for the database, or if the external storage is performing poorly, it may be necessary to move the database onto a new internal partition.
ISSUE
If there is not enough disk space for the database, or if the external storage is performing poorly, it may be necessary to move the database onto a new internal partition. The purpose of this, as a troubleshooting step, is to eliminate issues with /_Stateless storage filling up from the size of the database or performance issues due to the database running off of the storage. These steps are more important when running on lower-performance storage (NFS or CIFS) and mandatory when using storage with external deduplication.
RESOLUTION
Verify the system is running release 9.0.0-12 or later. If it is not, an upgrade must be performed before proceeding.
Next, from the hypervisor, create a new thick provisioned (lazy zero is OK) virtual disk in a high performance storage location of at least 100GB (300-500GB it the typical safe range, but large appliances protecting more than 50TB of data may require 1TB or more.) and attach it to the UEB. Larger UEB instances may require a larger database partition (up to 1TB for a 943 sized virtual appliance). This disk must be at least twice the size of the existing database to migrate an existing system. This attached disk must be brand new with no prior data on it. This should also be a blank disk. Do not expand backup storage onto this disk.
(Note: If you want to add another virtual disk for additional storage, this will need to be done before moving the database to its own partition. If you move the database first and then try to add storage, the appliance will not let you add it and return messages stating there is an existing file system and only allow you options to erase or recover, after choosing either, it will still not add. In some cases this will even log you out of the UI.)
The existing size of the database may be determined using the du command:
cd /backups du -ksh UnitrendsDataBase/
Verify there are no unneeded disks or external passthrough disks attached to the UEB, or disks from other virtual machines that were being backed up (such as those added through hot-add).
From the command line, download and run the newdisk script:
wget https://sftp.kaseya.com/utilities/newdisk chmod +x newdisk ./newdisk
The output from this script will include the path of the disk that was added (in this case, /dev/sdd):
Available added disk = /dev/sdd
Open a screen session to prevent the process from being interrupted. Note the path, and then call the cmc_stateless command to move the db to that path:
screen cmc_stateless dbpart /dev/sdd
NOTES
This process is also documented in the newest release of the Administrator Guide for Recovery Series and Unitrends Backup:
http://guides.unitrends.com/documents/rs-ueb-admin-guide/?_ga=2.149455025.660439065.1510267286-251382080.1435767216#satori/appliance_settings.htm?Highlight=Create%20a%20separate%20database%20partition