Six months after finishing a photo book, someone asks for another copy. You find three files named “final,” a missing linked image and a cover sized for a page count you no longer remember. The book may still look complete on a shelf while its production record is unusable.
Build a release folder when you approve a book, while the decisions are still clear. This guide separates the files needed to reproduce an approved edition from the working files needed to revise it. It is for personal projects and small collaborative books, not a guarantee that any printer can reproduce an old edition identically.
Define the edition you are preserving
Choose a project code and release label, such as RIVER-ED01-R01. “ED01” identifies the edition; “R01” identifies this approved production release. You can use another convention, but write its meaning down. Avoid “latest” as the only identifier because its meaning changes.
Gather the approved interior and cover PDFs, editable layout, linked images, text files, permissions and credits, production specifications, and the approval record. Work with copies while organizing. Do not delete your existing working folder just because a new archive folder exists.
Create a folder another person could understand
The following is a suggested structure. It is deliberately plain and does not require a particular publishing application.
RIVER-ED01-R01/
00-readme-and-manifest/
01-originals/
02-edited-images-and-text/
03-layout-and-linked-assets/
04-approved-print-files/
05-proof-and-approvals/
06-rights-and-credits/
Keep original photographs unchanged in 01. Put the actual edited images used in the book in 02 or the application’s collected-assets folder, documenting which is authoritative. Keep the editable layout and its dependencies together in 03. Put only the approved production files in 04; rejected exports belong elsewhere with clear labels.
If your application offers a package or collect function, use it and then check its report. Packaging cannot create missing links or automatically grant permission to redistribute fonts. Record font names, versions and licensing information; include font files only when permitted. Where your software supports a suitable interchange format, save that alongside the native document, without assuming the interchange file preserves every feature.
Write a manifest that resolves real ambiguities
Create a text document or spreadsheet with these fields. The values below are a fictional example, not YourBookBound production specifications.
| Field | Example | Why it matters |
|---|---|---|
| Release | RIVER-ED01-R01; approved 14 October 2026 | Identifies the snapshot |
| Interior file | river-ed01-r01-interior.pdf; 48 PDF pages | Prevents selecting an earlier export |
| Cover file | river-ed01-r01-cover.pdf; template reference stored with it | Connects the cover to its production setup |
| Trim and page delivery | 6 × 9 inches; single interior pages | Distinguishes page size from a spread preview |
| Paper and binding | Exact wording copied from the confirmed job specification | Avoids relying on “the nice matte one” |
| Approval evidence | approval-2026-10-14.txt, naming both PDFs | Links approval to specific files |
| Known limitation | Digital proof approved; no physical production sample reviewed | Prevents an unsupported physical-match claim |
Add the application and version used, export settings, any required colour profile, the person responsible for the archive and where the backup copies live. Do not guess missing settings. Write “not recorded” and resolve anything needed for reprinting before sending files.
A file checksum can help identify whether a file has changed, but it does not prove that its contents are correct. For a nontechnical archive, an unambiguous filename, file size, page count and stored approval are already more useful than a mysterious “final-final” folder.
Back up images separately from the editing catalogue
If you use Lightroom Classic, its catalogue backup does not replace a backup of the actual photographs and exports. Adobe’s catalogue backup documentation explicitly separates those tasks. Retain the catalogue and associated data as well as the source images and edited outputs your project needs.
A preview that displays correctly inside an application is not proof that the full-resolution original is present. Open several actual image files from the release folder, including one heavily edited file and one file used near the end of the book. Check the layout for missing-link warnings rather than relying only on the page preview.
Make independent copies, then test a restore
The Library of Congress recommends organizing important digital photographs, keeping copies in different places, and checking that they remain readable. Its personal photo archiving guidance is a useful foundation. A release folder also needs the layout, approvals and specifications that turn photographs into a reproducible book.
One practical arrangement is a working copy, a backup on separate storage, and another protected copy at a different location. Check whether a cloud service offers recoverable history: automatic synchronization may propagate a deletion rather than preserve an independent older state. Choose storage and access controls appropriate to the privacy of the photographs.
- Copy the completed release folder to the chosen backup destinations and record the date.
- Restore one backup into a new, clearly named test folder. Do not overwrite the working release.
- Open the restored interior and cover PDFs. Check page count, dimensions, first and last pages, captions and several image details.
- Open a copy of the restored layout. Confirm that its links resolve to restored assets, not silently to the original working folder. Relink within the test copy if necessary.
- Export a short test PDF and compare those pages with the approved PDF. Inspect fonts, image crops and page order.
- Record the result and any missing component. Retain the existing files until the restore works.
If you can restore the print PDFs but not the editable layout, label that result honestly: “Approved print files recoverable; editing dependencies incomplete.” It may be enough to request the same production job, but not enough to promise future revisions.
Decide whether a request is a reprint or a revision
An unchanged approved PDF is a starting point for a reprint, not proof of an identical physical result. Ask the printer to reconfirm current paper, binding, trim, cover template and file requirements. A changed paper stock or page count can affect the cover setup. Review a suitable proof when physical matching matters.
If you correct a name, replace a photograph or add pages, create a new release folder and approval record. Do not overwrite R01 with R02 files. Carry forward the rights and credit records, then check whether the change affects captions, contents, page references or the cover. A two-page addition can have consequences beyond those two pages.
Repair common archive failures
Only a low-resolution sharing PDF survives: look for the original production export and editable sources. Do not simply enlarge the sharing file and call it print-ready.
The layout opens with different fonts: identify the intended typefaces and licensing before substituting them. A replacement can change line breaks and pagination, so it requires a new review.
Two files both appear approved: trace the dated approval to exact filenames. If the evidence is inconclusive, obtain a new approval rather than choosing by modification date alone.
A backup exists but cannot be opened: treat it as a failed recovery, preserve other copies, and investigate without overwriting them. Schedule a repeat readability check; the Library of Congress suggests checking photographs at least annually.
The archive is ready when you can recover the approved PDFs, identify the edition and its limitations, and explain what is required to revise it. When another copy is needed, submit the approved files for checking with the manifest’s production details. Share the files needed for that job, rather than the entire private archive.