Backing up a graphic studio: the 3-2-1 rule for large data

The loss of an ongoing project or an archive of old projects can bring a studio to a standstill for days, even without any attack: a failed disk, a faulty file transfer or an accidentally deleted folder is enough. Studios also face a specific problem: data volume. Backing up hundreds of GB to several TB of photographic, video or 3D material requires a different approach than backing up standard office documents.

Rule 3-2-1

The 3-2-1 rule states: keep at least three copies of data, on two different types of storage, with one copy off the main workplace.

For large studio datasets, this means in practice, for example: the original on a NAS in the studio (see our article about NAS and large file management), a second copy on another device or drive, and a third copy off-site: either in the cloud or at a physically different location.

With large data volumes, it must be expected that offsite copies are not transferred over the internet as quickly as over a local network, backing up tens of TB to the cloud may take days to weeks for the initial upload, while subsequent increments (changes only) are significantly faster.

What to back up differently: active projects versus archive

Work in progress requires frequent, ideally automatic, deposits, daily, or even multiple times a day for critical projects. This is where the most losses occur if something fails mid-task.

Completed and handed-over jobs should be moved to an archive: a separate storage that is backed up less frequently but retained for longer. The archive does not unnecessarily burden the main storage and keeps order between what is "live" and what is already finished.

It is worthwhile to have a clearly defined period for archiving completed orders and ideally to reflect this in communication with the client, when and for how long their data will be available for any subsequent adjustments.

Data recovery: what is actually backed up

A backup that has never been tested by restoration is merely hope, not a backup. It pays to regularly attempt to actually restore a file or an entire folder from the backup and verify that it works and takes a reasonable amount of time.

With large data volumes, recovery time must be factored in, restoring several TB of data from the cloud can take significantly longer than from a local backup. If the studio needs to resume operations quickly, it makes sense to have a local backup copy as the first line of recovery and the cloud or offsite storage as insurance against worse-case scenarios.

It is advisable to keep backups separate from regular access - for example, versioned or made read-only after upload - as protection against errors or file corruption being automatically overwritten into the backup.

Protection against data overwriting and damage

Apart from hardware failure, studio data faces a quieter risk: a corrupted file, an erroneous write or accidental deletion that spreads to the backup before anyone notices. It is therefore advisable to configure at least part of the backup chain so that older versions remain available after the next backup run, rather than each backup simply overwriting the previous one.

In practice, this means a combination of snapshots or versioned backups (see our article about NAS and large file management) with regular checks to confirm the backup process has actually completed: a silent, long-overlooked backup failure is just as dangerous as having no backup at all.

It is also advisable to have someone on the team (or an external IT partner) who regularly checks the status of backups and reports if anything has not proceeded as planned. Backups that run "automatically" without any supervision tend to fail precisely when no one notices for a long time, and this is usually the most expensive scenario of all.

Where to connect deposits

Backing up completed projects also relates to how files are ultimately delivered to the client. This is addressed in the article about secure data handover to the clientActive projects are typically created directly in Adobe Creative Cloud, where versioning at the application level also needs to be considered, see the article about Adobe Creative Cloud administration in the studio.