Background
A national silkscreen and large-format printing company called us when production storage filled up yet again. The workarounds were not keeping pace.
Each job runs on high-resolution artwork, separations, and proofs. Files are big, the library grows every week, and repeat orders mean someone will ask for a job from years back.
Business Challenge
Production servers ran out of space on a regular schedule. They had added a proprietary SAN, but the answer was always the same: more disk shelves, less free rack space.
When disks filled, operators copied jobs to external HDDs. Manual work, unlabeled drives, and a shelf of disks that might—or might not—hold the job you needed for a reorder.
Active work needed to stay online, but closed jobs had no proper home. Staff spent hours on data instead of print.
Solution
We built a Linux production platform sized for the jobs in flight—without the proprietary SAN licensing stack or the quarter-by-quarter disk shelf purchases.
Closed jobs go to tape on a schedule. Tape control uses their job numbers: an operator moves a finished job to an archive folder, and the next tape run writes it to the library and frees space on production storage. Archive capacity runs several times larger than active storage—the headroom a print library needs over many years.
Implementation
We mapped how jobs already moved through the shop before writing any automation. Their job numbers drive the tape index—the same numbers on the work order.
When a job is done, staff drop the folder in the archive path. A scheduled run writes waiting jobs to tape and records which tape holds which job number. Restores start there—not from a pile of external drives with handwritten labels.
Project Considerations
External HDD copies had been a stopgap, not a system. Without a central index, every reorder meant guessing which drive to plug in.
The SAN bought time but consumed rack space. At some point the room was the bottleneck, not the budget line for disks.
Tape only pays off if folders and job numbers stay consistent. We spent time upfront on that layout so archive runs did not have to guess.
Environment Comparison
| Previous Environment | Current Environment |
|---|---|
| Legacy servers constantly out of space; production stops when disks fill | Linux production storage sized for active separations and artwork |
| Proprietary SAN that kept growing—more shelves, less rack space | Capacity grows on tape; production rack stays stable |
| Emergency offloads to external HDDs; fully manual; no central index | Tape archive indexed by job number with scheduled runs |
| No reliable way to find closed jobs for reorders | Look up the job number, load the tapes, back in production |
| Operators copying folders to USB drives when production fills | Staff move finished jobs to the archive folder; tape runs handle the rest |
| Archived jobs offline with no reliable index | Tape library catalogued by job number; active and archive tiers kept separate |
Key Outcomes
- Production storage under control — active jobs on Linux; closed jobs roll to tape on schedule
- Rack space recovered — stopped the cycle of new disk shelves for the SAN
- Restore by job number — find the job, load the tapes—back over lunch for a reorder
- Operators back on print — not copying folders to external drives when production fills
Long-Term Track Record
Production storage has stayed manageable over many years. They stopped adding disk shelves just to keep the SAN fed.
Active jobs stay on the production tier; closed work lives on tape, indexed by job number. For a reorder, someone looks up the job, loads the tapes the system lists, and the files are back on production storage over lunch—ready to run again. Customers do reorder from old artwork; the archive gets used.
Operators run print. We run the storage and tape side.