Chapter 37: Workflow, File Management, and Archive

Overview

Ask a room full of working video professionals for their worst-day-on-the-job story and you will hear the same shape of horror over and over. The drive that clicked once and never spun again — with the only copy of a wedding on it. The client who came back eight months later wanting a small change, and the project that would no longer open because half its media lived on a laptop that had since been wiped. The forty hours of edit gone in the half-second it takes to empty a Trash you were sure was empty of anything important. Nobody in that room is a bad editor. Every one of them is telling you about the day they learned, expensively, that talent is not what protects your work. A system is.

Here is the quiet truth this chapter is built on: the single most reliable difference between an amateur and a professional is not the quality of their best shot. It is that the professional never loses work. They can hand you a project from three years ago and open it in ten minutes. They have never once shipped the wrong version, never re-shot something because they misplaced the footage, never lost a client's trust to a dead drive. This is not because they are luckier or more careful in some mystical way. It is because, long ago, they built a handful of dull, boring habits — how they name a file, where they put it, how many copies exist, and what happens to a project when it wraps — and then they stopped thinking about those habits and just did them, every time, forever.

Those habits are the whole subject of this chapter, and they are learnable in an afternoon. Chapter 27 gave you the inbound half of this — how to ingest a shoot safely, organize it into folders and bins, and get it playing so you could cut. This chapter zooms out from that one edit to the whole life of a project and the whole life of your work: how to structure every project the same way, name every file so it survives, back up so a disaster is an inconvenience and not a catastrophe, run your drives so the edit is fast, and — the part almost nobody teaches — how to archive a finished piece so it reopens cleanly a year later and how to hand it off so someone else can continue it. None of it is glamorous. All of it is what "professional" actually means when the drive fails and the client is on the phone.

In this chapter you will learn to:

• Build a folder structure that is identical on every project and scales from a single phone clip to a multi-camera shoot.
• Adopt a file naming scheme whose names still make sense on a different computer, in a different program, in a different year.
• Apply the 3-2-1 backup rule so that no single failure — dead drive, stolen bag, spilled coffee, ransomware — can ever cost you a project.
• Choose the right drive for each job — scratch, working, backup, archive — by speed, capacity, and cost.
• Archive a wrapped project and hand it off so future-you, or anyone else, can open it and continue.

Learning Paths

This chapter is pure professional discipline, and it serves the 💼 Pro-track and 🎓 Student reader hardest — but the 📱 phone-first shooter who thinks "I don't have enough footage to bother" is exactly the person who loses their first real project. Weight your attention like this:

• 📱 Phone-first: §37.1 (a structure even for phone clips), §37.3 (3-2-1 — a phone plus a cheap external plus free cloud is a 3-2-1 system), and the naming rules in §37.2. Skim §37.4's drive detail; you need less of it.
• 🎥 Creator: §37.1 and §37.2 keep a high-volume, weekly output findable a year later, and §37.5 (archive) is how you go back and cut a "best of" without hunting through chaos. This chapter is what lets your back catalog become an asset.
• 💼 Pro-track: all of it, cold. This is the invisible thing a client is really buying when they hire "someone who won't lose the footage." §37.5 (archive) and §37.6 (handoff) are what separate a freelancer from a professional; a lost project is a lost client.
• 🎓 Student: the whole pipeline, and the most examinable ideas are the distinctions — storage vs backup, backup vs archive, and why RAID and sync are neither. The Production Checkpoint applies all of it to your three projects at once.

37.1 A project folder structure that scales

Chapter 27 taught you to organize one edit: you built the folder tree in FIGURE 27.2 — footage, audio, music, graphics, project files, proxies, exports, docs — and mirrored it as bins so any clip was findable in seconds. That was the folder structure the edit needs. Now we widen the lens all the way out, because the professional does not invent that tree fresh each time. They use the same tree, in the same shape, on every project they have ever done or ever will do — and they extend it to cover not just the edit but the entire life of the job, from the brief that started it to the archive that outlives it.

That is the idea to install. A folder structure (project-wide) is the complete, top-level organization of all of a project's assets — media, project files, documents, exports, deliverables, and the eventual archive — arranged in one consistent shape that you reuse identically for every job. The word that matters is identically. The power of a folder structure is not that it is clever; a dozen clever structures would work. The power is that it is the same one, every time, so that your hands know where the room tone lives, where the signed release lives, where the delivered master lives, without your brain having to get involved. Findability, which Chapter 27 taught you to value inside a single edit, becomes a property of your entire working life.

FIGURE 37.1 — A project-wide folder structure (the same skeleton on every job)

  THE LIBRARY  (where all your work lives — one home, never the Desktop)
  ───────────────────────────────────────────────────────────────────
  /VIDEO/
  ├── _TEMPLATE_PROJECT/        ◄─ an empty copy of the tree below; you DUPLICATE it per job
  ├── 2026/
  │    ├── 2026-03_CAFE-OWNER_website-promo/     ◄─ ONE project (date_client_what)
  │    ├── 2026-04_RIVERSIDE_documentary-short/
  │    └── 2026-06_ACME_product-launch/
  └── _ARCHIVE/                 ◄─ wrapped projects moved off the fast drives (see §37.5)

  ONE PROJECT  (open any project folder and it is ALWAYS this shape)
  ───────────────────────────────────────────────────────────────────
  2026-04_RIVERSIDE_documentary-short/
  ├── 01_FOOTAGE/          camera originals — the masters, never edited in place
  │    ├── CAM-A/          (sub-divide by camera / day / scene only as the shoot needs)
  │    ├── CAM-B/
  │    └── B-ROLL/
  ├── 02_AUDIO/            recorder files, room tone, VO
  ├── 03_MUSIC-SFX/        licensed tracks + their LICENSES (see §37.5 / Ch.38)
  ├── 04_GRAPHICS/         logos, stills, motion-graphics project files, FONTS, LUTS
  ├── 05_PROJECT/          the edit project file(s) and auto-backups
  ├── 06_PROXIES/          disposable, regenerable — NOT part of the archive
  ├── 07_EXPORTS/          the master + every deliverable (see Ch.36)
  ├── 08_DOCS/             brief, script, shot list, call sheet, releases, invoices
  └── 00_README.txt        one page: what this is, specs, where the master lives

Read FIGURE 37.1 as two nested claims. The library level is a claim about where projects live: one root folder for all your video work, projects named so they sort by date and are named for the client and the job, and a template you literally duplicate to start each one. The project level is Chapter 27's edit tree, grown up: the same numbered folders (numbered so they sort in workflow order, not alphabetically — you learned this in §27.2), now explicitly including a 07_EXPORTS for the master and deliverables you will make in Chapter 36, an 08_DOCS for the brief and the signed releases you will sort out in Chapter 38, and a one-page 00_README that will let this project be understood by a stranger — including future-you, who is a stranger.

The single most useful move in the whole figure is the _TEMPLATE_PROJECT folder. Build the empty skeleton once — all the numbered folders, empty, with a blank README — and keep it. To start a new job, you duplicate the template and rename it. That is it. Every project you ever make now begins life already organized, before a single file exists, which is the only time organizing is truly free. The reader who takes one thing from this section: make the template today, and never start a project any other way again.

"Scales" is the other word in the section title, and it means something precise. A one-person, one-clip phone job and a three-camera, five-day documentary use the same skeleton — the small job just leaves most branches empty or collapses them (a phone talking-head might have 01_FOOTAGE with no camera sub-folders at all, an empty 03_MUSIC-SFX, and a single deliverable in 07_EXPORTS). You never have to decide "does this project deserve structure?" The answer is always yes, because structure is free when it is a template, and the small project that had structure is the one you can still open in two years when it unexpectedly matters.

⚠️ Common Mistake: a brand-new "system" for every project (or no system — the Desktop). Two failures, same root cause. The first: you organize every project a little differently — this one has a "clips" folder, that one has "raw," another dumps everything at the top level — so returning to an old job means re-learning where you put things, if you can find them at all. The second, worse one: no structure, everything on the Desktop or in Downloads, media and exports and random screenshots in one heap. The fix is the template. Decide your structure once, freeze it, and clone it forever. The goal is that "where does this go?" is never a question you answer with thought — only with muscle memory.

✂️ In the Edit. Picture the cost of skipping this, because it is a real afternoon of a real life. A client emails: "Loved the video — can we swap the logo at the end and re-export?" Simple. Except the project was cut on a laptop that has been reset, the media was on "a drive, one of these three," the final logo was a file someone AirDropped you named logo (2).png, and the fonts in the title are gone. What should be a fifteen-minute change becomes a two-day archaeological dig — if it is possible at all. Now picture the same email landing on a project built from FIGURE 37.1: you open _ARCHIVE, find 2025-11_CLIENT_promo, open 05_PROJECT, and you are making the change before your coffee is cold. The structure you build on the way in is what makes the work reopenable on the way back. That is the entire bridge from this chapter to the rest of your career.

🔄 Check Your Eye. 1. What is the one property that gives a folder structure its power — and why does it matter more than the specific tree you choose? 2. What is the _TEMPLATE_PROJECT folder for, and how do you start a new job with it? 3. Why do a one-clip phone job and a five-day shoot use the same skeleton?

Check yourself

1. That it is identical on every project. Any reasonable tree works; what saves you is reusing the same one every time, so finding things becomes muscle memory instead of thought.
2. It is an empty copy of your standard project tree. You duplicate it and rename it to start each new job, so every project begins already organized — the only time organizing is free.
3. So you never have to decide whether a project "deserves" structure. The small job just leaves branches empty; structure is free from a template, and it is the small forgotten project that most often needs reopening later.

37.2 File naming that survives

A folder tells you where a file lives. The file's name tells you what it is — and a name is the one piece of information about a file that can never get separated from it. Strip away the folder, email it, drop it on a stranger's computer in a different program a decade from now, and the name is still there, still doing its job or still failing at it. That is why professionals treat naming as seriously as they treat exposure. File naming is a deliberate, consistent scheme for naming files, clips, and folders so that each asset's identity — the project, the date, where it came from, what it contains, and which version it is — is legible from the name alone and sorts correctly on any machine. A good name is a tiny label welded to the file. A bad name is a lie you tell your future self.

You met the edge of this in Chapter 27: a clip called A017_C0022 off the camera tells you nothing, while DOC_INT-A_maria_t03 tells you the project, the setup, the subject, and the take. Chapter 27 asked you only to be "consistent and sortable." This section makes it a scheme you can trust for life.

FIGURE 37.2 — The anatomy of a name that survives

  2026-04-12_RIVERSIDE_int-A_maria_t03_v02.mov
  │          │         │     │     │   │
  │          │         │     │     │   └── VERSION   two digits: v01, v02 (never "final")
  │          │         │     │     └────── TAKE      zero-padded: t03 (so t10 sorts after t09)
  │          │         │     └──────────── SUBJECT   who / what: maria, espresso, exterior
  │          │         └────────────────── SLOT      the setup / role: int-A (interview cam A)
  │          └──────────────────────────── PROJECT   short, stable code: RIVERSIDE
  └─────────────────────────────────────── DATE      ISO 8601: YYYY-MM-DD — sorts chronologically

  THE RULES THAT MAKE IT SURVIVE
  ──────────────────────────────
  • Dates as YYYY-MM-DD, always. 2026-04-12 sorts correctly; 4-12-26 and "April 12" do not.
  • Zero-pad every number: 01 02 ... 09 10 11.  Un-padded 1,2,...,10 sorts as 1,10,11,2,3...
  • NO spaces. Use - between words, _ between fields. Spaces break links, scripts, and URLs.
  • NO special characters: / \ : * ? " < > | & # % are forbidden or dangerous on some systems.
  • Front-load what you sort by (here, the date). The most important field goes left.
  • Keep a PROJECT code short and stable — it will appear on hundreds of files.
  • Lower-case (or ONE consistent case). Some systems treat File.mov and file.mov as the same.

Every rule in that box is scar tissue — each one exists because someone lost time to its absence. Take them one at a time. ISO dates (YYYY-MM-DD) are the single highest-value habit here: because the fields go big-to-small, the text sorts into true chronological order for free, so a folder of daily exports lines up like a timeline instead of the nonsense that 4-12-26 produces. Zero-padding fixes the maddening bug where clip10 sorts before clip2 because the computer compares character by character; write clip02 and clip10 and they line up right. No spaces and no special characters is about portability: a space or a slash or an ampersand in a filename is fine until the day that file travels through a link, a web upload, a backup script, or a different operating system, and then it silently breaks — the classic cause of "media offline" that has nothing to do with the media at all. And front-loading the field you sort by lets you re-sort a whole folder just by choosing what goes on the left.

Then there is versioning, which deserves its own paragraph because it is where naming discipline most often dies. You have seen the meme; you may have lived it: report_FINAL.docx, then report_FINAL_v2.docx, then report_FINAL_v2_USE-THIS-ONE.docx, then report_really-final-THIS-one-actually.docx. It is a running joke precisely because it is universal, and it is a disaster in an edit, where "which export did I send the client?" is a question with real money attached. The fix is a boring, rigid convention: versions are _v01, _v02, _v03, zero-padded, incrementing, and the word "final" never appears in a filename, because "final" is a lie the moment there is a revision. When a cut is truly locked, you can add one unambiguous tag — _LOCK or _APPROVED-2026-04-20 — but the version number is what you trust. Two digits, always climbing, never "final."

⚠️ Common Mistake: renaming a file after you have imported it (media offline). This is the naming mistake that bites hardest, because it feels harmless. You import your clips, then decide the names are ugly and rename them on disk — and your whole project lights up with "media offline," because the project file stored the old names as pointers and now cannot find them. As Chapter 27 warned: once media is imported, its files are load-bearing; the project references them by name and location. Name it right at ingest, before you import — or rename inside the project, never on the disk underneath it. Get the name correct once, at the very start, and never touch it again.

💡 Why It Works: the name is the metadata that cannot fall off. A file can carry information in lots of places — folder location, database tags, a sidecar file, the project's internal labels. Every one of those can get separated from the file: the folder changes, the database is on another machine, the sidecar gets left behind. The name is the only label physically attached to the bytes, so it is the only description guaranteed to travel with the file everywhere it ever goes. That is why professionals cram the essentials — date, project, source, content, version — into the name itself. You are writing the one caption that can never be lost.

⚙️ Settings Box: a naming scheme you can adopt today. A starting convention to standardize, not a law of physics — but standardize something, and standardize it forever.

Asset	Pattern	Example
Camera clip	DATE_PROJECT_slot_subject_take	2026-04-12_RIVERSIDE_int-A_maria_t03.mov
Audio	DATE_PROJECT_recorder_scene_take	2026-04-12_RIVERSIDE_zoom_int_t03.wav
Project file	PROJECT_edit_vNN	RIVERSIDE_edit_v07.drp
Export / deliverable	PROJECT_deliverable_spec_vNN	RIVERSIDE_youtube-1080p_v03.mp4
Master	PROJECT_MASTER_spec_DATE	RIVERSIDE_MASTER_prores-4k_2026-04-20.mov
Folder (project)	DATE_CLIENT_what	2026-04_RIVERSIDE_documentary-short

Front-load the field you most want to sort by (date for time order, project for grouping). Keep project codes short and CAPS so they jump out. Never use "final"; always use _vNN.

🔄 Check Your Eye. 1. Why write a date as 2026-04-12 rather than 4/12/26 in a filename? 2. What breaks if you name clips shot1, shot2, ... shot10 instead of shot01 ... shot10? 3. Why is renaming a file on disk after importing it a classic way to cause "media offline"?

Check yourself

1. ISO YYYY-MM-DD sorts into true chronological order as plain text (big-to-small fields), and it is unambiguous across regions; 4/12/26 sorts wrong and could be April 12 or December 4.
2. They sort in the wrong order — shot10 and shot11 fall between shot1 and shot2, because text is compared character by character. Zero-padding (shot01) fixes it.
3. The project stored the file's original name/location as a pointer; renaming the file underneath breaks that pointer, so the project can no longer find the media. Rename before import, or only inside the project.

37.3 The 3-2-1 backup rule

Everything so far protects your work from chaos — from not being able to find it. This section protects it from destruction. And it starts with the one sentence that, if you truly believe it, will save you a career's worth of catastrophes: a single copy of anything is not a backup. If it exists in only one place, it does not exist.

That sounds dramatic until you count the ways one copy dies. Drives fail — mechanical drives seize, solid-state drives quietly stop mounting, and both do it without warning and often within a few years. Laptops are stolen and dropped and spilled on. Cards corrupt. Folders get dragged into other folders and deleted. Ransomware encrypts everything on a machine, including the "backup" folder on the same machine. Fire and flood take whole rooms. Against that list, one copy is not a plan; it is a bet you place every single day, and the house always wins eventually. The professional answer is a rule old enough and simple enough to memorize in one breath.

The 3-2-1 backup rule: keep at least three copies of your data, on at least two different types of media or devices, with at least one copy kept off-site (physically elsewhere, or in the cloud). Three, two, one. Each number kills a specific way of losing everything, and understanding which is what makes the rule stick instead of feeling arbitrary.

FIGURE 37.3 — The 3-2-1 backup rule (each number defeats a different disaster)

                          YOUR PROJECT
                               │
        ┌──────────────────────┼──────────────────────┐
        ▼                      ▼                      ▼
   COPY 1                 COPY 2                 COPY 3
   working drive          backup drive           OFF-SITE
   (internal / edit SSD)  (external HDD)          (cloud, or a drive
        │                      │                   at another location)
        │                      │                      │
   ┌────┴──────────────────────┴────┐            ┌─────┴─────────────────┐
   │  TYPE 1: fast local drives     │            │  TYPE 2: different     │
   │  (same building, same room)    │            │  medium AND location   │
   └────────────────────────────────┘            └───────────────────────┘

   3 COPIES  ► one drive will fail; two might; three, rarely all at once.
   2 MEDIA   ► so a single failure MODE (bad drive batch, one controller,
               one filesystem bug) can't corrupt every copy at once.
   1 OFF-SITE► so a LOCAL disaster — fire, flood, theft, ransomware, a
               dropped bag — cannot take every copy in one event.

   NOT a backup:  a second folder on the SAME drive · RAID (that's uptime,
   not backup) · a sync folder that mirrors deletions to every copy.

Walk the three numbers. Three copies, because any one drive has a real chance of failing, and if your "backup" is your only other copy, then the day your working drive dies you are down to one — and one is none. Three copies means a failure is a shrug: you make a fresh copy from the survivors and move on. Two kinds of media, because copies that share a failure mode can die together — two drives from the same bad manufacturing batch, two files on the same filesystem hit by the same bug, two SSDs plugged into the same failing hub. Mixing types (an SSD and a spinning HDD, a local drive and the cloud) means no single failure mode reaches all your copies. One off-site, because the disasters that hurt most are not about drives at all — they are about rooms. A fire, a flood, a break-in, a spilled drink across a desk, a ransomware infection that spreads across everything plugged into one computer: every one of those takes the whole room, and every copy in it. The off-site copy is the one that is somewhere else when the room is gone.

🚪 Threshold Concept: storage is not backup. This is the idea that permanently changes how you look at a file. Beginners think of a drive as a place their work is safe. It is not; it is a place their work is stored, which is a completely different thing. Storage is where a copy lives. Backup is the existence of another copy whose entire job is to be there when the first one dies. A file on one drive — however expensive, however new, however "professional" the drive — is stored, not backed up, and it is one ordinary failure away from gone. Once you internalize this, you stop asking "is my drive reliable?" (no drive is reliable enough to trust alone) and start asking "how many places does this exist?" That question, asked as a reflex, is what a professional's paranoia actually is.

The two most common fake backups deserve to be named, because both feel like safety and neither is. RAID is not a backup. A RAID array (several drives ganged together so the system survives one drive dying) buys you uptime — the machine keeps running when a disk fails — but it does nothing against the deletions, corruptions, ransomware, theft, and fire that actually eat projects, because those hit the whole array at once. RAID is wonderful and it is not a copy somewhere else. Sync is not a backup, either. A folder that automatically mirrors to the cloud or another drive feels like a backup, but its job is to make every location identical — which means when you delete a file, or a corruption creeps in, the sync faithfully propagates the deletion or the corruption to every copy. A true backup keeps history: older versions you can roll back to. Sync keeps sameness. Know the difference, because the day you accidentally delete a folder, sync will have helpfully deleted it everywhere, instantly.

🎒 Gear Note: building 3-2-1 on any budget (yes, including phone-only). 3-2-1 is not a rich-professional's setup; it is a shape you can hit at every budget, and the phone-first reader can hit it this week.

• The floor (phone + free): your footage on the phone, copied to one cheap external drive, and synced to a free-tier cloud account. That is already three copies, two media types, one off-site. Total spend: one small drive.
• The solo creator: a fast external SSD as your working drive, a larger external HDD as a local backup, and a paid cloud plan (or a second HDD you keep at a friend's/parent's/office) as the off-site. This is the standard freelancer rig and it is not expensive.
• The volume shop: a NAS (networked drives) for working storage and local backup, plus cloud or LTO tape (see §37.4/§37.5) off-site for archives.
• The principle under all of it: the number of independent copies matters more than the quality of any one drive. Three cheap copies in three situations beat one expensive drive every time. Do not spend up to one perfect drive; spend out to three ordinary ones.

Here is how 3-2-1 connects to what you already do. Back in Chapter 27, at ingest, you learned the non-negotiable floor: never wipe a card until two verified copies exist elsewhere. That "two verified copies" was 3-2-1 in miniature — the piece you needed to safely start an edit. This is the full rule, running for the life of the project: from the offload, you are never again below three copies across two media with one off-site, from the first card to the final archive. The card discipline was the on-ramp; 3-2-1 is the road.

⚠️ Common Mistake: the two drives that die together. The most common way a careful-seeming person still loses everything: they do keep two copies — a working drive and a backup drive — and they keep both in the same bag, on the same desk, plugged into the same laptop, in the same room. That is three copies of the location. The bag is stolen, the desk floods, the power surge or the ransomware or the toddler reaches all of them at once, and "I had a backup!" turns out to mean "I had two copies of the same vulnerability." Two copies in one room is one copy for every purpose that matters. The off-site copy is not optional garnish; it is the specific thing that makes a backup a backup.

🔄 Check Your Eye. 1. State the 3-2-1 rule, and say what disaster each of the three numbers defeats. 2. Why is RAID not a backup? Why is an automatic sync folder not a backup? 3. Complete the threshold idea: "If it exists in only one place, ______."

Check yourself

1. 3 copies (a drive will fail; three means a failure is a shrug), on 2 media types (so one failure mode can't reach every copy), with 1 off-site (so a local disaster — fire, flood, theft, ransomware — can't take every copy at once).
2. RAID gives uptime, not a separate copy — deletion, corruption, theft, and fire hit the whole array. Sync keeps every location identical, so it propagates deletions and corruption to all copies and keeps no history to roll back to.
3. ...it does not exist. (A single copy is storage, not a backup.)

37.4 Scratch disks, drives, and speed

Sections 37.1 through 37.3 were about safety — never losing work. This one is about speed — the fact that not all your copies do the same job, and that the drive an edit runs on has to be fast enough to keep the edit from fighting you. Chapter 27 showed you one answer to a slow edit (proxies, which shrink the files); the other half of the answer is the drives, and matching the right drive to the right task is a quietly professional skill.

Start with the vocabulary of speed. A drive's usefulness for an edit comes down to how fast it can read and write — its throughput, loosely "megabytes per second" — and drives fall into rough tiers. The important thing is not the exact numbers (they change every year) but the order, because the order tells you which drive belongs on which job.

FIGURE 37.4 — Drive tiers: match the drive to the job (fast/small/costly at top)

  TIER            ROUGH SPEED*        BEST JOB                    NOTE
  ──────────────  ─────────────────   ─────────────────────────  ────────────────────────
  Internal NVMe   very fast           OS + SCRATCH / cache        fastest; usually smallest
   SSD            (~1,000s MB/s)      (render cache, proxies)     keep some free space!
  External SSD    fast                WORKING drive (the         great edit drive; pricier
   (over a fast   (~500–1,000+ MB/s)  active project you're       per TB than spinning disk
    port)                             cutting right now)
  Spinning HDD    slow-ish, cheap     BACKUP + ARCHIVE            big & cheap per TB; fine
   (external)     (~100–250 MB/s)     (copies at rest, not the    for copies you don't edit
                                       drive you edit on)          off; mechanical, will die
  NAS / network   varies widely       SHARED working + backup     team access; speed depends
                                                                   on the network
  Cloud           limited by your     OFF-SITE copy + collab      the "1" in 3-2-1; slow to
                  internet            (not a live edit drive)      pull back a whole project
  LTO tape        slow, sequential    deep ARCHIVE (cheapest      not random-access; for
                  (but huge/cheap)    per TB, long shelf life)     "store and rarely touch"
  * Ballparks that shift yearly — trust the ORDER, not the exact figures.

Two ideas do most of the work in that figure. The first: you edit on a fast drive and you keep copies at rest on cheap ones. The active project — the media you are scrubbing back and forth all day — wants to live on an internal or external SSD, because a slow drive turns high-bitrate footage into a stuttering slideshow no matter how good your computer is (this is the drive-side twin of the codec problem from Chapter 3 and the reason for proxies in Chapter 27). Your backups and archives, by contrast, are copies at rest — you are not editing off them — so they belong on big, cheap, spinning HDDs (or tape, or the cloud) where the low speed does not matter and the low cost lets you afford the redundancy 3-2-1 demands. Do not waste fast, expensive storage on copies that just sit there; do not try to edit off a slow archive drive.

The second idea is the scratch disk (also called the cache): the working scratchpad your editing software uses for temporary files — render cache, generated proxies, waveform and thumbnail data, optimized media. Three things to know about it. It should live on a fast drive (it is read and written constantly), it should not be the same drive that holds your only copy of the media (both to spread the load and because filling your system drive with cache can choke the whole computer), and it is entirely disposable — the scratch/cache can always be regenerated, so it is never something you back up or archive. Point your editor's scratch to a fast drive with room to breathe, and keep an eye on it, because a cache that silently swells to fill a drive is a classic cause of a computer grinding to a halt mid-edit.

⚙️ Settings Box: which drive for which job. A sane default rig; adjust to your gear and budget.

Job	Drive	Why
OS + apps + scratch/cache	Internal NVMe SSD	Fastest; cache is hammered constantly and is disposable
Working drive (active edit)	External SSD on a fast port	Smooth 4K/high-bitrate playback and scrubbing
Backup (local copy at rest)	External spinning HDD	Big and cheap; you don't edit off it, so speed is irrelevant
Off-site copy	Cloud, or an HDD stored elsewhere	The "1" in 3-2-1; survives a local disaster
Deep archive (wrapped jobs)	HDD (2 copies) or LTO tape	Cheapest per TB; store, verify periodically, rarely touch

Never edit off your backup or archive drive. Never let the scratch/cache share the drive that holds your only media copy. Keep ~10–20% of any working drive free.

🔬 The Tech: interfaces, and why "USB" isn't one speed (skippable). Skip this and you lose nothing essential — but it explains a real frustration. A drive's speed is capped by two things: the drive itself and the port it connects through. The same external SSD can be fast or crippled depending on the cable and port: older USB connections are far slower than current ones, and the fastest external connections (often branded Thunderbolt, or the newest USB standards) approach internal-SSD speeds. The confusing part is that the connector shape no longer tells you the speed — two ports that look identical can differ by a factor of ten. The practical rule: for a working edit drive, use a modern external SSD on the fastest port your computer offers, and if playback stutters on footage that should be fine, suspect the cable and port before you blame the drive. For backups and archives, none of this matters — a slow port is perfectly fine for copies at rest.

🔄 Check Your Eye. 1. Which drive type belongs under an active edit, and which under backups and archives — and why the split? 2. What is a scratch disk / cache, and what are the two rules for where to put it? 3. Why is it fine for an archive drive to be slow, but not your working drive?

Check yourself

1. The active edit belongs on a fast drive (internal or external SSD) so high-bitrate footage plays without stuttering; backups and archives are copies at rest, so they belong on big, cheap, slow spinning HDDs (or tape/cloud) where speed doesn't matter and low cost funds redundancy.
2. It's the editor's disposable temporary working files (render cache, proxies, thumbnails). Put it on a fast drive, and not on the drive holding your only media copy — and never back it up (it regenerates).
3. You don't play footage off an archive — it just stores copies at rest — so slowness is invisible there. A working drive has to feed the timeline in real time, and a slow one turns playback into a stuttering slideshow.

37.5 Archiving a finished project

The project is delivered. In Chapter 36 you exported the master and the deliverables, the client is happy, and the fast SSD that project lived on is now needed for the next job. Most people, at this moment, do one of two bad things: they leave the finished project sprawled across their working drive until it is full, or they delete it to make room and gamble that no one will ever ask for it again. The professional does a third thing, and it is the thing this section is about. They archive it.

An archive is the deliberate, long-term preservation of a finished project's essential files after delivery — trimmed of the disposable junk, gathered into one organized package, copied to durable storage, and arranged so the project can be reopened, understood, and even re-edited years later. Notice how an archive differs from a backup, because conflating them is a classic error. A backup protects active work against loss right now; it is a live safety net you are constantly updating. An archive preserves finished work for the future; it is a sealed package you make once, at wrap, and then leave alone (while still keeping it safe — an archive gets 3-2-1'd too). Backup is for the work you are doing. Archive is for the work you have done.

The heart of archiving is a single question, and it is the test you apply to every choice: could I reopen this in a year — or five — and have everything I need? That test tells you exactly what to keep and what to throw away.

FIGURE 37.5 — The archive package: what goes in the box (and what doesn't)

  RIVERSIDE_documentary-short_ARCHIVE_2026-04-20/
  ├── 00_README.txt          ◄─ the manifest: what this is, software+version, frame rate,
  │                             resolution, where the master is, fonts/LUTs used, delivery specs
  ├── 01_FOOTAGE/            ◄─ KEEP: camera originals (the masters) — irreplaceable
  ├── 02_AUDIO/              ◄─ KEEP: recorder files, room tone, VO — irreplaceable
  ├── 03_MUSIC-SFX/          ◄─ KEEP: tracks + their LICENSE files (prove your rights — Ch.38)
  ├── 04_GRAPHICS/           ◄─ KEEP: logos, stills, motion project files, FONTS, LUTS
  ├── 05_PROJECT/            ◄─ KEEP: the final project file (fine cut / locked timeline)
  ├── 07_EXPORTS/            ◄─ KEEP: the MASTER export (+ the delivered versions)
  └── 08_DOCS/               ◄─ KEEP: brief, signed releases, invoice, delivery notes

  LEAVE OUT (disposable / regenerable — do NOT bloat the archive):
    ✗ 06_PROXIES/     regenerate from originals anytime
    ✗ render cache / scratch      the editor rebuilds it
    ✗ duplicate or draft exports  keep the master + final deliverables only
    ✗ camera/card folder junk     (empty THMB/misc system files)

  THEN: 3-2-1 THE ARCHIVE.  Two copies on durable media, one off-site.
  An archive on a single drive in a drawer is one flood away from never existing.

The keep/throw logic is entirely driven by the reopen-in-a-year test. You keep everything irreplaceable — the camera originals (your masters; you can re-cut from them but you can never re-shoot them), the clean audio, the music with its licenses, the graphics and their source project files and the fonts and LUTs they depend on, the final project file, and the master export. You throw out everything regenerable — proxies (remake them from the originals), render cache (the editor rebuilds it), and the pile of draft and duplicate exports (keep the master and the final deliverables; the seven intermediate versions are noise). An archive bloated with disposable files is slower to make, more expensive to store in triplicate, and no safer. Lean is part of the discipline.

Two moves turn a folder into a real archive. The first is to consolidate: use your editor's media-management or "archive project" function to gather the project and all the media it actually uses into one self-contained folder, so nothing is left pointing at a file on some other drive that will not exist next year. In DaVinci Resolve — the free suite this book anchors to — this is the Export Project Archive function, which packages the project file together with its media into one portable bundle; the equivalent "collect / consolidate files" command in other software is mapped in Appendix E. Whatever the button is called, the goal is frozen: one folder that contains everything, with no external dependencies. The second move is the README manifest — a plain-text page, sitting at the top of the archive, that tells future-you what this is: the software and version it was cut in, the frame rate and resolution, where the master export is, which fonts and LUTs it uses, the delivery specs, and any password or account the project depends on. It takes five minutes and it is the difference between an archive you can open and a puzzle you have to solve.

⚠️ Common Mistake: archiving the deliverable instead of the project — or archiving to one drive. Two failures gut an archive. The first: keeping only the final exported video and deleting the project and originals to save space. Now you have the movie but you can never change it — no re-edit, no fix, no new cut for a different platform, no pulling a clip for your reel. The exported file is the destination; the originals and the project are the ability to go there again, and that ability is what an archive is for. The second failure: making one beautiful, complete archive... on a single drive, in a drawer. An archive is data like any other — one copy is not a backup, and it certainly is not preservation. Archive the originals and the project, not just the export, and put the archive in at least two places with one off-site. An un-backed-up archive is just a slow way to lose things later instead of sooner.

🔬 The Tech: archives rot if you ignore them (skippable). An archive is not "write once, forget forever," and pretending otherwise is how institutions lose history. Two clocks are ticking. First, the media dies: spinning drives left in a drawer can fail to spin up after a few years, and even SSDs can lose data if unpowered for very long; tape lasts longer but not forever. The defense is migration — every few years, copy your archives onto fresh media and verify them (a checksum, like the verified copy from Chapter 27, catches silent "bit rot" before it spreads). Second, the formats and software age: the program your project was cut in, the codec your master is stored in, even the connector on your drive can become obsolete faster than you expect. The defense is to keep your master in a widely-supported, high-quality format (Chapter 36's advice) and to migrate long-lived archives forward before the tools to read them disappear. Serious archives — studios, national film libraries — do exactly this on a schedule: refresh the media, verify the checksums, migrate the formats. For your own work, "check and re-copy the archive every few years" is the amateur-proof version of the same wisdom.

♿ Accessibility & Inclusion. Archive the accessibility work, not just the picture. The caption/subtitle files (the SRTs), the transcript you made back at sync time (Chapter 27), and any audio-described or alternate-language versions all belong in the archive alongside the master — because the day someone re-releases this project, or repurposes a clip, or is legally required to caption it, having those files already made and preserved turns a re-do into a copy-paste. Accessibility is expensive to recreate and cheap to keep. An archive that preserves the captions and the transcript is an archive that stays reachable to everyone the next time the work goes out.

🔗 Connection. Archiving ties three chapters together. The master you preserve is the high-quality master you were taught to keep in Chapter 36 (§36.4) — deliverables are disposable, the master is not. The releases and licenses in 08_DOCS and 03_MUSIC-SFX are the legal paperwork you will sort out in Chapter 38 (§38.4–38.5); an archive without them is a project you cannot legally re-use. And the archive is what makes Chapter 39 possible: when you cut your three projects into a demo reel, you will be pulling from these archives — which is only painless if you archived cleanly here.

🎬 On Set (at the desk): archive one finished project. Take a project you have actually finished — one of your three, ideally — and archive it properly, start to finish. Consolidate the project and its used media into one folder; strip the proxies, cache, and duplicate exports; write the 00_README manifest; and copy the whole package to two durable drives with one off-site. Constraint: when you are done, rename your working copy's media folder (simulating a dead drive), then open the archived project from the archive alone and confirm every clip is online and nothing is missing. Self-review: if anything came up "media offline," your consolidate missed a dependency — find it, add it, and re-verify. An archive you have tested is the only kind you can trust.

🔄 Check Your Eye. 1. In one sentence each, how does an archive differ from a backup? 2. What is the single test that decides what goes into an archive and what gets left out? 3. Why is keeping only the final exported video — and deleting the project and originals — a mistake?

Check yourself

1. A backup protects active work against loss right now (a live, updated safety net); an archive preserves finished work for the future (a sealed, one-time package you make at wrap and keep safe long-term).
2. "Could I reopen this in a year and have everything I need?" Keep everything irreplaceable (originals, audio, project, master, fonts/LUTs, licenses); leave out everything regenerable (proxies, cache, duplicate exports).
3. The export is the finished destination but not the ability to change it — no re-edit, no fix, no new cut, no clip for your reel. The originals and project file are what let you go back; that ability is the whole point of an archive.

37.6 Handoff and project portability

There is one situation the archive test does not fully cover, and it is common enough to deserve its own section: the day the project has to leave your machine. A collaborator takes over the edit. A client asks for the project files. You move to a new computer. You reopen your own archive on a system that has changed. In every case the question is the same — will the project actually open, whole, somewhere other than where it was built? — and the answer, by default, is often no. That is the problem of portability, and solving it is the last habit in this chapter.

A project handoff is packaging a project so it can be opened and continued on a different computer, or by a different person — with every piece of media, every dependency, and the project file itself traveling together and relinking cleanly on the other side. The reason handoff is hard, and the reason a naively-copied project opens to a wall of "media offline," is the thing Chapter 27 taught you at ingest: a project file is not your media — it is a set of pointers to your media. Copy the project file to a new machine without its media, or with its media in different places than the pointers expect, and the pointers dangle. Portability is the craft of making the pointers relative and making their targets travel along.

FIGURE 37.6 — Making a project portable: consolidate, package, relink

  THE PROBLEM (naive copy — pointers dangle)
    project file ──►  points at /Users/me/Desktop/clips/... (only on YOUR machine)
    on new machine:   those paths don't exist  ──►  "MEDIA OFFLINE" everywhere

  THE FIX (a self-contained package)
    ┌──────────────────────────────────────────────────────────┐
    │  RIVERSIDE_HANDOFF/                                        │
    │  ├── project file          (the pointers)                 │
    │  ├── 01_FOOTAGE/  02_AUDIO/  03_MUSIC-SFX/                 │
    │  ├── 04_GRAPHICS/  ├── FONTS/   ◄─ or titles reflow/substitute
    │  │                 └── LUTS/    ◄─ or the grade looks wrong
    │  └── 00_README.txt (software+version, frame rate, specs)  │
    └──────────────────────────────────────────────────────────┘
         everything the project needs lives INSIDE one folder,
         referenced by RELATIVE paths ─► copy the folder anywhere,
         open the project, media relinks from right beside it.

  THE DEPENDENCY TRAPS (what breaks a handoff even when the video is there):
    ✗ missing FONTS   → titles substitute a wrong font, reflow, or vanish
    ✗ missing LUTS    → the color grade loads wrong or not at all
    ✗ missing PLUGINS → effects go offline; the other machine lacks them
    ✗ missing MUSIC/GRAPHICS source → gaps where linked files should be

The fix has two parts, and they mirror the archive. First, consolidate everything into one folder referenced by relative paths. The most reliable way is your editor's project-packaging function — the same Export Project Archive in Resolve that packaged your archive, or the generic "collect / consolidate files" elsewhere (Appendix E) — which copies the project file and its media into a single self-contained bundle whose internal links point within the bundle rather than at absolute locations on your specific machine. Keep your media inside the project folder from the start (as FIGURE 37.1 does) and this is easy; scatter media across your drives and it is a scavenger hunt. Second, include the dependencies the video secretly needs but the timeline does not obviously show: the fonts your titles use (miss them and Chapter 34's beautiful lower-thirds reflow or substitute into something wrong), the LUTs your grade relies on (miss them and Chapter 32's look loads incorrectly), any music and graphics source files, and a note about any plugins or effects the other machine will need to have installed. These are the traps that make a handoff "open" and still be broken — the picture is there but the fonts are wrong and the grade is off — and they are exactly what a good package and a good README head off.

The README earns its keep again here, because a handoff is a message to someone who was not there when the project was built. It should say what the piece is, the software and version it was cut in (a project can fail to open in an older version), the frame rate and resolution, the delivery specs, where the master lives, the list of fonts and LUTs, and whom to contact with questions. Ninety seconds of writing saves the recipient an afternoon of guessing — and since the most frequent recipient of your handoffs is future-you opening your own archive, that afternoon you save is usually your own.

✂️ In the Edit. This is where the whole chapter's discipline either pays off or comes due, and it is worth feeling the two futures. In the bad future, a great client calls a year later wanting the project handed to their new in-house editor — and you spend two unbillable days hunting media across three dead drives, recreating a grade because the LUT is gone, and apologizing for the missing fonts, while the client quietly decides you are not as professional as they thought. In the good future, the same call: you copy one self-contained package from your archive, drop it in the shared drive, and the new editor opens it that afternoon with every clip online, every title correct, every grade intact, and a README answering their questions before they ask. Same talent, same footage. The only variable is whether, a year ago, you built the project to travel. Handoff is not a task you do at the end; it is a property you design in from the folder structure onward.

🔗 Connection. The business side of handoff is Chapter 38: who owns the project files — you or the client — is a question your contract should answer before the shoot, not an awkward negotiation when they ask for the files (§38.2, §38.5). Some clients pay for the final video only; some pay for the project and originals too. Either way, an organized, portable project is what lets you deliver on whatever the contract says. And when you cut your reel in Chapter 39, you are, in effect, handing your past projects off to your future self — which only works if you can open them.

💡 Why It Works: relative beats absolute. A pointer can describe a file's location two ways: absolutely ("the clip at /Users/me/Desktop/clips/a.mov on this exact machine") or relatively ("the clip in the 01_FOOTAGE folder right next to this project file"). Absolute pointers break the instant the project moves, because that exact path exists on only one computer. Relative pointers survive the move, because "right next to me" is still true wherever the folder lands. This one distinction is the entire secret of portability: keep media inside the project folder and reference it relatively, and a project becomes something you can copy anywhere and open. It is the same reason a self-contained archive reopens in a year — the project and its media are neighbors, and neighbors move together.

🔄 Check Your Eye. 1. Why does a project file copied to a new machine so often open to "media offline"? 2. Name three dependencies — beyond the video and audio clips — that can break a handoff. 3. Why does keeping media inside the project folder, referenced by relative paths, make a project portable?

Check yourself

1. A project file is only pointers to media, not the media itself. Copied without its media — or with its media in different places than the pointers expect — the pointers dangle and the project can't find its clips.
2. Fonts (titles substitute/reflow), LUTs (the grade loads wrong), plugins/effects (they go offline on a machine that lacks them), and music/graphics source files. (Any three.)
3. Because "the file right next to this project" stays true wherever the folder is copied, while an absolute path exists on only one machine. Relative references travel with the folder, so the media relinks automatically on the new system.

Production Checkpoint

All three projects — archive and back them up so you could reopen any of them in a year. This is not a shooting assignment; it is the professional habit that protects everything you have built across this entire book. You have three finished (or nearly finished) projects — the talking-head, the documentary short, and the branded piece. It is time to make each one unloseable and reopenable.

For each of your three projects, do the full pipeline from this chapter:

1. Structure and name. Put the project into the standard folder structure from FIGURE 37.1 (retrofit it if you were messy — this is the last chance to do it painlessly), and confirm the files are named so a stranger could tell what they are.
2. Archive it. Consolidate the project and its used media into one self-contained package; strip the proxies, cache, and duplicate exports; write a 00_README manifest (software + version, frame rate, resolution, where the master is, fonts/LUTs, delivery specs); and confirm the master export and the signed releases/licenses are inside.
3. 3-2-1 it. Copy each archive to at least three places, on at least two kinds of media, with one off-site (cloud or a drive kept elsewhere). No project may exist in only one location.
4. Test the reopen. For at least one project, open it from the archive alone (rename or unplug the working copy first) and confirm every clip is online, the titles use the right fonts, and the grade is intact.

Why this matters: a project you cannot reopen is a project you did not really finish — and a portfolio that lives on one drive is a portfolio one failure away from gone. The reel you will cut in Chapter 39 is built entirely from these three archives; the client who comes back in a year is served entirely by whether this step was real. This is the checkpoint that turns "I made three videos" into "I have three assets I will never lose." Do it now, while all three are fresh in your hands.

Summary

• A folder structure (project-wide) is the complete organization of all a project's assets in one shape you reuse identically on every job. Its power is sameness; build a _TEMPLATE_PROJECT and duplicate it forever.

• File naming welds a file's identity to the file itself. The rules that make names survive:

• 3-2-1 backup: 3 copies, on 2 media types, 1 off-site. Storage is not backup; a single copy does not exist. RAID (uptime) and sync (sameness, propagates deletions) are not backups. The Chapter 27 floor — two verified copies before wiping a card — was 3-2-1 in miniature.
• Drives by job: edit on fast (SSD); keep copies at rest on cheap/slow (HDD, tape, cloud). The scratch/cache goes on a fast drive, not on your only media copy, and is disposable.
• Archive = long-term preservation of a finished project (keep the irreplaceable — originals, audio, project, master, fonts/LUTs, licenses; drop the regenerable — proxies, cache, duplicate exports). Test: could I reopen this in a year? 3-2-1 the archive too, and migrate it before the media or format dies.
• Project handoff / portability: a project file is pointers, not media. Consolidate media inside the project folder, reference it relatively, include the hidden dependencies (fonts, LUTs, plugins, sources) and a README. Relative beats absolute; neighbors move together.
• The throughline: the professional never loses work — not through talent, but through dull habits done every time.

Spaced Review

Retrieval from Chapter 27 — the inbound half of this chapter's outbound discipline. Answer before you check.

1. (Chapter 27) What are the two halves of ingest, which one must come first, and how does that "offload first, two verified copies" rule relate to the full 3-2-1 backup rule in this chapter?
2. (Chapter 27) What is the difference between a folder and a bin — and how does this chapter's project-wide folder structure extend the edit-only folder tree you built in §27.2?
3. (Chapter 27) What is a proxy, why must you switch back to originals before export, and why must the originals — never the proxies — be what you preserve in an archive?
4. (Chapter 27) Why does renaming or moving a media file after it has been imported cause "media offline," and how do this chapter's naming and portability rules prevent it?

What's Next

Your three projects are now delivered (Chapter 36), and — as of this chapter — organized, backed up beyond the reach of any single disaster, and archived so you could reopen any of them in a year. The work is protected. What is not yet protected is the business around the work: whether you have the signed releases from the people on camera, whether your music is actually licensed for the use you put it to, who owns the project files you just archived, and what all of this is worth in money. Those questions sat quietly in your 08_DOCS and 03_MUSIC-SFX folders throughout this chapter, waiting. Chapter 38 opens them: contracts, pricing, licensing, releases, copyright, and how to manage the scope of a job so it stays profitable and protected. You have learned to make video and to never lose it. Now we make it pay.