Before you install ManageEngine’s ServiceDesk Plus, you’re going to need to understand the way in which the system consumes disk space to make sure that you’ve allowed for growth. There are some options for managing disk space after installation, but the longer you leave it (and the less free disk space you have when you want to make any change), the harder it will be.
I’m not going to talk very much about this, mainly because there are well-trodden paths for managing the space consumed by databases and their log files, and for controlling the specific drives that those files sit on.
Predicting disk space usage for the database and logs is also difficult. It will, obviously, hugely depend on how you’re using the system: for example, how many Requests per month, how you’re using email within SDP, whether you’re scanning PCs or other network devices, and how long you’re retaining that scan history.
ServiceDesk Plus requires a minimum of 20gb free hard disk space. We know that because it says so in the System Requirements. But then those of us with long enough memories will also know that Windows XP will run with 64mb RAM. Well, it will drag itself across the ground on 64mb RAM anyway. So perhaps it’s worth looking beyond the official system requirements.
A plain installation of ServiceDesk Plus is going to consume around 500mb of disk space. If you’re running MSSQL or MySQL on the same server, you’ll want to consider the disk space needs for your database application as well.
The main thing that will increase the size of the application installation is patching SDP. Every time you apply a patch, SDP is going to:
- Take a copy of the PPM file (the patch file) and copy it into the \ServiceDesk\Patch folder
- Expand out the PPM file into its component files into a sub-folder in the same location.
You should allow at least 100mb per patch file, and how many of these you have will depend on whether you’re installing every build as it’s released or making larger jumps. To give some context, version 8.2 was released at the beginning of April 2013 and in mid-November, we’re now on patch 13.
SDP does not clean these files up after the patch has been successfully installed – they’re there permanently. That said, given that SDP does not support uninstalling a patch after installation has completed, you may feel that you can go in manually and trim some of the older patch files and their respective sub-folders. I’ve certainly done this when I’ve been short of disk space to no ill effect (so far!)
Attachements to tickets (and other things) are not stored within the database. Instead, they’re stored in the file system.
Firstly, the \fileAttachments folder is located by default under the \ServiceDesk folder. This contains any files attached to:
- Problems (the Impact, Symptoms, and Root Cause fields all allow you to attach files)
- Notifications and Conversations (inbound and outbound emails relating to Requests)
- Contracts (if you’re using the Contracts module, obviously)
How much disk space will you need for these things? It depends. Sorry, not very helpful, but there you go.
If you’re interacting with users via email, then you may see a lot of growth here. We get a lot of large Word documents, PowerPoint presentations and PDF files attached to incoming Requests. Often, these need to be modified and sent back. Very roughly, the \fileAttachments folder has grown 1gb for every 10,000 Requests. 60% of that is in the \Requests folder, 25% in the \Notifications folder, 10% in \Notifications, and not very much anywhere else.
Your mileage may vary.
Since build 8114, SDP has allowed you to configure the location of the \fileAttachments folder. This is done from Admin | Self-Service Portal Settings, a strangely named option in the admin interface that contains a number of settings they couldn’t find anywhere else for.
This allows you to move what could be a rapidly growing data folder off the OS partition and onto a data partition or even a network share. If you’re taking it off the SDP server itself, make sure that the link between the SDP server and the file server you choose is fast enough, although since all of these files are downloadable attachments rather than components of the page itself, putting the data on a file server shouldn’t affect page load times.
The best time to make this change is straight after you install SDP, but in fact you can do it at any time and it is extremely painless. You change the path in the option above, click Save, and SDP will move all the files from the current attachment path to the new one. It creates a new \fileAttachments folder in the location you specify here.
Whereas the \fileAttachments folder contains files that have been attached to Requests, Problems, etc, the \inlineImages folder contains embedded images from Requests and other modules. If a user pastes a screenshot from their computer and emails it to you, or you paste an image into the rich text editor fields in SDP, those images are stored in this location. These files can relate to:
- Requests (using the common SDP alias of WorkOrder for the folder name)
- Conversations (inbound and outbound emails relating to Requests)
- Signatures (the E-mail Signature Technicians can set by clicking Personalize)
Unlike the \fileAttachments folder, there is no option to relocate the \inlineImages folder to another drive. The reasoning is probably because access time for these files will affect page load speed, but it presents a problem. The size of this folder can be significant, depending on usage. For us, this folder is 20% of the size of the \fileAttachments folder.
This is where it all gets tricky.
The SDP backup process effectively builds a large zip file made up of the following:
- Everything from the \fileAttachments folder
- Everything from the \inlineImages folder
- Everything from the \custom folder – images and CSS files for your SDP instance’s appearance
- Select files from the \bin folder
- Select files from the \server folder
- Licence info
- SQL files representing the data in your SDP database
The default configuration is that the backup files are built and stored in the \backup folder. This starts with generating the SQL scripts for the data backup. Then, the backup process zips up all the other files listed above before finally adding the SQL files as well. It then deletes the SQL files.
It is possible to change the backup location for scheduled backups only – under Admin | Backup Scheduling, click Edit Scheduling and specify a backup location. There are some limitations to this config change that you need to be aware of, however. First of all, it applies to where the final backup file is placed, and not necessarily to all of the temporary files created along the way. Importantly, fileAttachments.zip – which contains a compressed copy of all the file attachments and online images – is created under the \servicedesk folder, regardless of where your file attachemnts are being stored and regardless of the backup location. This can place significant demands on the application partition. Once all the file attachments and online images have been compressed into this file, it is incorporated into the backup file itself and deleted. Precisely how this incorporation in executed is unclear, but I have noticed that where you are backing up to the default folder location, the amount of free disk space required on that partition can be as much as twice the final backup file size, so I suspect the operation is more copy than move.
The other limitation to this confg setting on backup location is that it only applies to scheduled backups: it does not apply to manual backups (ie, those created by running backupdata.bat in the \bin folder), nor does it apply to backups created whilst applying a patch to SDP. On that last point, I’d note that prior to build 8213 there appeared to be a bug that meant that even if you said ‘No’ to the option to backup as part of the patch process, it performed a backup anyway. Also, there seem to be certain upgrades, such as when going from 81xx to 8200, where you aren’t even offered the choice not to perform a backup.
In larger SDP implementations, especially those with large volumes of attachments and inline images, it can be the backup process that will cause you the biggest capacity issues: even if you have moved the \fileAttachments to a different drive or to a network location, you will still need to allow space for it on the drive containing your SDP application for those occasions where you have to do a manual backup or a backup as part of an SDP patch. (Of course, there are some ways to cheat if you really have to.)
Our experience – and again, yours may vary, is that we’re getting around 25% compression in the backup files – so if you total the \inlineImages folder, \fileAttachments folder, and database, your final backup size will be around 75% of that. You may need an extra 10% for working space whilst the backup is in progress. I’m assuming that you will have a process in place to move the backup file off the SDP server, so I’m mostly concerned about the working space required here. For those of you retaining your backups in place, I’d also point to the option within Backup Scheduling to have SDP purge backup files older than a given age.
There are a few other bits and pieces that will take up space, but they’re all second order compared with the three areas above. For example, when you generate reports to be emailed as attachments, SDP creates the files within the application folder and doesn’t clean them up itself. There are log files, but only the most recent logs are retained, so there is a limit to how much space they will consume.
As with any server installation, it’s important to consider disk capacity requirements in advance. There are some things you can do to control where ServiceDesk Plus places its files and where, therefore, that disk space is consumed. However, there are also some limitations. You need to watch the amount of free disk space available on the application drive carefully otherwise you can end up in a mess.
Image credit: Norlando Pobre