Where Is Your Pinakes?

This time, I’ll talk about your content — and where it lives
Publish date:
Social count:
This time, I’ll talk about your content — and where it lives

So far in this series about disaster management and recovery, I�ve outlined simple ways to get started on a workable disaster recovery plan for your station and described useful IT tools to help you prioritize what you need to do to prepare for an incident. This time, I�ll talk about your content � and where it lives.


Here�s a case study from the third century A.D. about disaster recovery, content, backups and metadata. Scholars disagree on the details of the construction of the Library of Alexandria, but the outlines are pretty consistent.

Image placeholder title

The library was part of a larger complex called the Museum of Alexandria, a center of research, knowledge and national pride for Egypt built in the third and fourth centuries A.D. Ptolemy I Soter, a general in Alexander the Great�s army, built it and sponsored scholars who worked there, who included Euclid.

Its charter was to collect all of the world�s knowledge in one place, and by most estimates, had at its peak several hundred thousand scrolls. Aside from searching out books at book fairs, scholars at the library employed a clever way to have books come to them: As ships came to the port of Alexandria, they were required to surrender any books to the library. The books were copied and the copies were returned to the traders, while the originals were stored in the library.

The library remains in our minds and in our culture today largely because it was destroyed in the legend of the burning of the Library of Alexandria. In the historical record there doesn�t seem to be one single burning event. The first incident was during the time Julius Caesar�s armies were besieged at Alexandria in 48 B.C. He ended up burning his own ships, which then accidentally ignited the library. Oops. There are other burnings in history, including Emperor Aurelian�s taking of the city around 270 A.D., then again in 391 as part of a purge of �pagan� institutions, and yet again in 642 A.D. by order of the Caliph Omar, among others. The library didn�t survive into the Dark Ages.

While some knowledge was lost � and that part is definitely a tragedy � remember that the vast majority of the scrolls in the library had copies in existence elsewhere. There were copies at libraries in Constantinople, Baghdad and Gondishapur � the sources of texts for the early medieval universities in Europe. Relatively little science and literature was irretrievably lost.

In modern terms, the library had an extensive set of backups, an important part of any disaster recovery plan. This was not a planned strategy; communication and moving items across long distances in classical times make it likely that scrolls were copied in other places simply so scholars could have access to them without going on long, dangerous journeys. Protection against disasters was at most a secondary consideration, but turned out to be the most important strategy for preserving knowledge into modern times.


So what was the real tragedy? The Library of Alexandria lost its way to find and use its content. The library had the first content index that used content and practical metadata to organize the collection and make individual works easily findable.

The Pinakes � ancient Greek for �tables� � was a 120-volume reference that listed the contents of the library and where to find individual works. Callimachus, a Greek scholar, invented it and created the system that divided the scrolls into six genres and five categories based on their content and their author. The Pinakes gave the location of the scrolls within the library and had an understandable way to not only discover if a particular work was in the library, but where to locate it. It was conceptually no different than a modern content management system; the only thing missing is playback.

Almost all stations and media organizations now have their own Pinakes in the form of centralized content management and playback systems. That�s the index; it�s the way you find and manage your station�s content. Instead of piles of CDs (and records!) stacked up in a library (or piled in the PD�s office) accessed by shuffling through physical objects, everything, including your interstitial matter and spots, are now organized and findable in one place.


Content management systems are driven by metadata associated with the content. Each item in your station�s content stores has metadata that describes each item by its content � length, genre, author/artist, etc., equivalent to the Pinakes� sorting scrolls by genre and category. Each item also has practical metadata that helps your content management system find and use it: items like file location, which content store it�s part of, the �real� file name (if your content management/playback system has �human� and �machine� names for the content items), et.al. This practical metadata is equivalent to the Pinakes giving the location of each scroll in the Library.

The Pinakes was a huge invention; it made content findable and usable by scholars. The combination of a huge collection of �all of the world�s knowledge� and a way to efficiently find works and combine ideas made the library and the museum the best place in the classical world to do research for a few hundred years.

It�s not clear when the Pinakes itself was destroyed or lost. At some point, scholars didn�t have a way to find the works they needed � or to figure out if a particular work was even still in the library. Major research stopped at the library and moved to places like Constantinople and cities farther east. It�s entirely possible that those research libraries had their own version of the Pinakes, a critical tool in information management that�s continued in various forms to today.


Think about how and where your content is stored � and how to mitigate the danger of losing it. If you still have a lot of physical media (like albums and CDs), take a good look at your library and think about how to back up that probably irreplaceable content somewhere offsite; this would be a good time to start thinking about a digitization project.

Let�s say you have been diligent about moving all your content into one (or more) content management systems/playback systems/archives. What happens to your ability to work and to play that content if you�re forced from your main studio?

Your disaster recovery plan must include an ongoing program of keeping offsite stores of the bulk of your content � even high-density disc backups are better than nothing. Keeping an identical copy of your content storage at your backup location is the best and fastest way to get back up-and-running again.

How often should you backup your content? That�s dependent on your RTO and RPO (remember, recovery time objective and recovery point objective from my last column?) analysis of how you use content at your operation. Some music stations may not need 100 percent of their primary storage available at a backup site, so they may have a very tolerant RPO and could stand to lose some content during an incident.

Some news stations, on the other hand, may need at least the last few weeks of news content available at the backup site; they have a much less tolerant RPO, which drives more frequent backups of your content at the recovery site. In those cases, daily isn�t too often, and a system that continuously backs up content as it�s posted in station storage may be a good way to go.

And you need your Pinakes, too. It�s not enough to simply have bulk storage backup; you need a way to find and play your backed-up content. This could be as simple as a standalone content management/playback system from the same vendor you use for your station�s playback systems. Make sure that the playback system can access and play from the content stores at your backup site. Think very carefully before putting in a system that�s different from the one that your staff is accustomed to using every day; it�s not a good idea to be working with unfamiliar tools during an incident.

Putting a playback system at your backup site is an investment; think back to your RTO and RPO analysis. How long can you afford to not have access to your stored content, including underwriting announcements or commercials, before it starts costing your station money and reputation?

Keep in mind that some incidents don�t involve your surrounding community and are invisible to your listeners; we�re talking about things like building power or HVAC failures that only affect your operation. In those cases, you need to keep your on-air presence as seamless as possible, which means that the old �drag a bunch of CDs to the transmitter� plan is now completely unworkable.

Are you covered if you have your content backed up in multiple places, and have good ways to find and play it? Possibly, but you can�t be sure until you test it � and that�s the next installment.

Bridgewater works with radio stations, program producers and other media companies to help them solve sticky problems, including analyzing and enhancing their disaster recovery preparations.


This Is a Drill promo image

This Is a Drill

You don’t have a working disaster recovery plan until you originate programming from your backup location and transmit to your community