I have read with interests comments on Joyent's blog of disgruntled users among which professional system administrators seemed to be found. Beyond the technical merits of the recovery it is quite clear that selling storage services with no backup scheme that would allow data to be available within a matter of hours or a day at best is a dangerous proposition for an internet startup boasting technical prowess. At best it casts a negative light on their understanding of what a backup is and that ultimately I store data remotely not because ZFS or Thumper are cool (they are) but because I hope to be able to retrieve it more elegantly and more simply than going to the bank to retrieve the tape from the vault.

Interestingly enough the brand leader in distributed storage, amazon has an interesting Service Level Agreement that worries solely about the service being available, not that data returned are immune to corruption. I am wondering whether the next step is going to be data insurance, against data loss and format obsolescence. Something to ponder.

In my context neither of these options are appealing since data are the bread and butter of my company, hence the painstaking off-site backup process to mitigate risks and the oh-so-enjoyable-but-needed task of spelling out a comprehensive disaster recovery plan.

I have been reading the technical documentation from our SAN vendor in order to connect their SNMP agent to our monitoring rig (a collection of cacti and awk/postgresql contraptions designed to operate as performance data warehouses). Since they use private MIBs it is only fitting that they provide detailed documentation on the various probes available. The probes in themselves are fine, but the documentation is not. To be more procise the documentation format is not. I very much concur with petermr that PDF is absolutely not the proper format for technical documentation. Technical documenation tends to be very structured and, in this particular case, we are looking at page after page of table-formatted probe description, and entries are very similar to each other. You might argue that the .mib file contains all that information in a very easy-to-parse format. I would agree except that it does not contain as much descriptive prose as the manual does. So PDF prints well but is too restrictive for that kind of data since it does not interface properly with external search tools. Who wants to print reams of OIDs anyway? I'd rather grep in this case. I'm not here advocating for the use of some rich and rigid SGML/XML schema since documentation has to be free-form enough to not constrain technical writers to a preconceived form. Quite the contrary, a microformat would probably work very well here. Even ascii art and pure free-form text would work better than PDF. So if you're an entreprise vendor, keep producing nice PDF slicks arguing about great ROI and low TCO, but please, keep your technical documentation grep-able.