I have been using CrashPlan Pro for almost 3 years and I have realized that, although the software is simple to use, knowing the internal workings of the software and how to build the system correctly are the only ways to guarantee a successful restore. Let’s start with the fundamentals.
- Although the CrashPlan Pro server works on multiple platforms, users are best served by hosting it on a Linux platform. The Linux platform offers users greater stability and speed over other platforms.
- For storage, I would select an ISCSI platform because of the low cost of ownership and its speed which allows it to handle any load the server might demand.
- Always have two storage groups, one for backing up the client machines and one for backing up the server. It is very simple in CrashPlan Pro to recover the server, however, to maintain historical records of all files, a backup of the archive must exist in case the primary storage fails.
- When calculating the storage speed, users must take into consideration the time it will take to back up the archive. For instance, if the primary storage on the server has 10 TB, the backup process will take an extremely long time if the Gig ports on the server and ISCSI are not being utilized.
- RSYNC is the user’s only friend when it comes to backing up the CrashPlan Pro server. It will allow users to do differential backups and it can run simultaneously with CrashPlan Pro.
- CrashPlan Pro, by default, does not run if the CPU utilization is higher than 20%. If the user is backing up a server, he must ensure that the utilization is less than 20% or increase it to guarantee that the backup runs at all times.
- For Exchange and SQL servers, run the native backup software/script first and then have CrashPlan Pro pick up those files. Something to note: the user should change the client’s Advanced Settings to prevent “backup open files” from occurring, as this will result in partial files that cannot be recovered.
- Audit and set alerts. During the lifetime of the CrashPlan Pro server, clients will exceed their storage quota, lose connectivity, etc and these instances can be programmed to alert the administrator. It does not hurt to log into the management interface occassionally to make everything is working properly.
- Before shutting down the server, the user MUST dump the database first, then shut down the CrashPlan Pro engine to minimize the risk of database corruption.
- Finally, and most importantly, TEST….TEST…and then TEST. Do not under estimate the need for testing the backups on a regular basis.
If you have any questions or need help with your existing installation, please feel free to contact me, Usama Houlila, at email@example.com.