In many video production environments it’s a challenge to both backup and archive production data.
This is because video data take a reasonable amount of disk space, and you don’t want to interrupt real-time ingest, playback, and playout by backing up your data.

One of the best ways to backup and/or archive your video data, is by using Quantum’s StorNext filesystem in conjunction with their StorNext Storage Manager.

StorNext is compatible with Apple’s Xsan filesystem, and it’s very easy to replace your existing Apple Xsan metadata controllers with Linux-based StorNext metadata controllers, which is a prerequisite if you want to implement Quantum’s StorNext Storage Manager.

What’s so special about the Storage Manager, though?

If you create files on your filesystem, there’s three ways for your backup and archive software to find out, that there are new files which need to be copied to a second storage device:

• The backup software can scan the filesystem for modified or freshly created files. This puts a reasonable amount of load on your storage, so this is an approach for environments with long backup windows. During real-time operations you usually don’t want to scan your central storage.
• The application, which writes a file, needs to inform the backup solution, that it has to back up a file. While this works between Final Cut Server and Archiware PressSTORE, e.g., this depends on the operability between your application and your backup/archive solution.
• The filesystem can send a filesystem event to your backup/archive app. This way your backup app doesn’t need to scan your whole filesystem and can write your data in a very efficient way.

Archiware PresSTORE supports filesystem events with HFS+ and Xsan 2.x volumes, so PresSTORE would be one way to back up your data without the need to scan your Xsan volumes for changed files.

Another way of doing this is the StorNext Storage Manager. The Storage Manager integrates with the StorNext filesystem, and can send freshly created or modified files to the backup and/or archive without scanning your central SAN volume.

In version 3.5.1 the Storage Manager runs on the active metadata controller, which under certain circumstances might cause so much load, that filesystem latency exceeds the critical limit for real-time operations. To deal with this, you can either schedule Storage Manager activity to run at uncritical times, or you use the brand-new StorNext Data Mover (part of StorNext 4.0), which means, that your primary MDC works as a MDC only, and a dedicated client machine actually moves files into the archive to keep your primary MDC responsive, even if there’s lots of Storage Manager activity going on.

Another great thing which comes with StorNext 4.0 is deduplication. Deduplication allows your filesystem to use less disk or tape space when it stores your data. If StorNext sees that a data block in a new file is the same like a data block in a file which is already part of the archive, then it doesn’t store that data block again, but instead creates a reference from the new file to the existing data block.
This is great for archive volumes, yet, on your primary (online) storage, this slows things down a bit, so you might want to turn on deduplication for your archive only, if you work in real-time environments.

If everything is set up properly using StorNext file system and Storage Manager, it allows you to work on your central storage without the necessity for backup/archive windows.

If you need help planning or implementing a StorNext based solution, please feel free to get in touch with me.