FreeNAS 9.10 – Fully Operational; Batteries Not Included
In our previous post, we were awaiting the completion of burn-in testing for the FreeNAS solution that we had constructed. Approximately 48 hours was required to complete the recommended short SMART test, the badblocks test, and the long SMART test on all four drives. With the firmware fully updated for the motherboard, out of band management controller, and the disks, we were off to the races. Initial tests and performance numbers were very impressive, but we encountered some unexpected issues and challenges within the first week of operation.
1.) A single early life failure on one of the four Seagate Constellation ES.3 drives. The beauty of taking a few minutes to set up e-mail alerts resulted in immediate notification when the drive failed and the pool entered a degraded state. As we were within the 30 day return period, we RMA’ed the drive and awaited receipt of the replacement unit. The new drive was definitely from a different batch and had the most recent firmware. Validation was successful and the fourth drive was added as a replacement for the first pool.
2.) There’s a CrashPlan plug-in available for FreeNAS. If you take that statement at face value, it wouldn’t appear any different than comparable, community-developed offerings for competing, commercial off-the-shelf solutions. However, the underlying story is far more complex and involves sifting through multiple processes to achieve a fully updated and operational jail with the current version of CrashPlan. Many of the posts we found were helpful and fairly accurate, but some commands and file names have changed over time. We have been performing off-site backups now for close to a week without issue, and reboots of the NAS to apply updates have not impeded operation of the backup solution in any way. The jail is rock solid and the services do not encounter issues when starting.
Having had enough time with the solution under our belt to formulate a solid opinion, the pros far outweigh the cons. The scheduling of standard maintenance tasks is very robust, development and updates come at a very fast pace, and the community – while terse if you didn’t take the time to RTFM – has enough experience to help resolve any issues that you may encounter. The notifications that can be e-mailed as soon as a non-standard event is detected go a long way in enabling the ability to proactively solve issues before they have a chance to take away the underlying data. The reporting mechanisms are very robust and easy to understand. Advanced networking functions have enabled multi-VLAN support and facilitated the appropriate path configuration for iSCSI storage without considerable effort, which is a significant benefit for our virtualized environment.
The fixes we’ve witnessed while researching the list of updates have promptly addressed errata for configurations that are even more extreme than ours. We’ve actually compiled yet another process that we’ll publish and share related to all things CrashPlan within a FreeNAS jail. The pending release of CrashPlan 4.7 in the near future will result in us taking a pause prior to publishing this body of work so that we can validate paths and file names for the newest packages. This will ensure the procedure will be current and valid for the foreseeable future. We’ve even uncovered some additional “gotchas” that occur when you take over an old CrashPlan backup set that had a different configuration (disk layout, IP address, etc.). Stay tuned!