PROBLEM:
Symantec Messaging Gateway refuses to do a backup. When the process is started from the console the error message is:
ERROR: There is not enough drive space available to perform the backup.
Space Required: <VERY LARGE NUMBER> kb
SYMANTEC SOLUTION:
The standard solution offered my Symantec Tech Support is to follow the instructions in articles TECH96749 and TECH198862. In some cases this is not enough to solve the problem.
OUR CASE:
After performing all the steps suggested by Symantec, we could not release additional disk space. Our appliance showed 56% free space and 44% used in the /data partition (64GB free out of 121GB total). We concluded that the problem was in the database itself. As we add data to a MySQL databases it keeps growing, but if we start erasing data, it does not release the disk space allocated to the database. In other words, the disk files containing the database or tables do not shrink. Of course, MySQL keeps track of space inside the files and the file won’t grow again until the new data is too much for the allocated space. To recover space a dump/restore process must be done.
To diagnose the problema, we took a look at the code of the db-backup utility. The db-backup utility does a sanity check and calculates the required disk space based on the allocated disk space used by the database, logs and probably other files. Running the command db-backup with option -–verbose we can see better what is happening. The calculated required space is 41140932k, and as the system Works with a ratio of 2 ($free_space_ratio = 2;), it demands double free space, that is 2*41140932k = 8281864k.
In our case, this sanity check prevents us from doing the backup, but it turns out that the free space shuld be enough. Why? Because there is a lot of unused space in the database files. So the dump will never be as big as the space allocated. We can get a better estimate of the space required for the MySQL database dump as described here: http://dba.stackexchange.com/questions/37159/how-can-i-determine-the-size-of-a-dump-file-prior-to-dumping/37168#37168
SUGGESTIONS TO SOLVE THESE ISSUES:
- Add a command line option to db-backup utility to allow admins to bypass the free space sanity check. Of course, the default should be to do the sanity check. Admins who know what they’re doing should be able to do the backup.
- Use the MySQL queries to estimate the disk space required instead of the raw space allocated by the database, as explained above.
- The mysqldump should be piped to the compressor, avoiding the need of a temporary file and saving gigabytes of space and time as the disk I/O will be lot less (tipically 10%). li>
- The scripts add files to a TAR file one by one. This is a slower than tarring all the files at one. In this case the tar command will be built by the script as it check which files will be added to tar and executed at one at the end. Note also that tar can compress files on the fly also and the script can take advantage of this.
These last two suggestions have the potential of improving the tool performance. The bigger the database, the bigger the savings.
