Raw data discs

Raw data discs

Raw mode puts original files on one disc, with checksums and optional PAR2 recovery in a hidden folder beside them. Files are directly readable, without DAR or an extraction step. One create run builds exactly one disc.

bd-archive create -s /data/incoming -n Photos-2026-10 -o /data/photos-2026-10

-m raw is optional because raw is the default. -n is required: it becomes the volume label and the name of the folder that holds the files on the disc.

Multisession is not supported and is not planned for the foreseeable future. You cannot add files to this disc after burning, even if it has unused space. Collect the files on disk before creation and burn the complete batch together. See Multisession support and research.

Workflow

1. create scans the source and groups it into indivisible units (--group-by, default: each direct subfolder and each file directly in the source).
2. It plans the source across discs in the chosen fill order (--order-by) and shows three plans: efficient, balanced and ordered. Each plan shows what fits on this disc, its recovery data and estimated size, what remains and how many further discs the rest needs.
3. You select a plan and review the volume label and disc layout. Then answer Create this disc? (y/N).
4. create builds the disc folder from the selected units, writes checksums, recovery data and the README, and checks the exact size.
5. Finally it asks Remove the N archived units from the source? (y/N). Answer y when you no longer need them in the source. With N (the default) the source stays unchanged, and the next run plans these units again.

A small source that fits completely yields a disc with everything; answer N at the end to keep the source as it is. A larger collection is archived over several runs, one disc each: burn the disc, then run create again on the same source with a new output directory and name. The next run plans only what is still in the source, including files that arrived in the meantime. No plan, history or numbering is stored between runs.

See Planning raw discs for grouping, fill order, content dates, the three plans and --max-free.

Choose recovery space

-r sets the recovery data every plan reserves and creation writes; the rest of the disc stays free. --fill-recovery additionally fills that free space with PAR2 data. Both options work the same way in DAR mode.

Setting	Result
Omit -r	Exactly 5% of the disc's data; the rest of the disc stays free
-r 1 through -r 100	Exactly this integer percentage of the disc's data
-r 500M or -r 2G	Exactly this amount of recovery data (decimal MB or GB)
-r 0 or -r none	SHA-512 checksums only, no recovery files
--fill-recovery	Additionally fill the remaining free space with PAR2 data
-r 0 --fill-recovery	No minimum; only the remaining free space is filled
-r none --fill-recovery	Rejected: none means strictly no recovery data

--fill-recovery is skipped on a disc when filling would add less than 0.5% of that disc's data, for example when the selected units already fill it. A notice names the amount that was not added; the disc keeps its -r minimum, or no recovery data with -r 0. Filling never prevents a plan: the free space is measured only after the units were selected.

Recovery is allocated in whole blocks and bounded by PAR2 limits, so some space can remain unused. A unit that does not fit on a disc including its minimum recovery data stops creation; choose finer grouping, larger media or a smaller -r. Raw recovery sizing accepts at most 32,768 non-empty files per disc. Fixed recovery uses explicit source/recovery block counts; rounding to complete blocks can exceed the requested percentage or size slightly.

During PAR2 creation one live line shows the current phase; Processing adds the average throughput and remaining time. All other PAR2 output stays visible. Without a terminal, progress is logged at most every 5 seconds.

PAR2 protects the contents of non-empty files, including attachments. It does not protect empty files, directory structure, filesystem metadata or the README. The SHA-512 manifest lists every file of the payload folder and every attachment, including hidden and empty files. See Verification for how the tool chooses between these checks.

Attach files to every disc

--attach PATH adds a file or folder to the disc root, for example an info file that belongs on every disc:

bd-archive create -s /data/incoming -n Photos-2026-10 -o /data/photos-2026-10 \
  --attach /data/disc-info/Info.txt

Repeat the option for several paths. Attachments count against every plan, are covered by checksums and PAR2, and are never removed from their location. They must be outside the source, must not overlap each other or the output/workdir, and need unique names (ignoring case). Their names must not collide, ignoring case, with the payload folder name (-n), README.txt, .bd-archive or the legacy root metadata names checksums.sha512, recovery.par2, recovery-volume names and .bd-archive-raw-v2. Symbolic links and special files are rejected.

How the disc folder is built

The selected units are brought into disc/<name>/ in the output directory, keeping their paths relative to the source. For each file, create uses the cheapest method:

1. Reflink (copy-on-write clone, for example on Btrfs or XFS): no extra space; later changes to either file stay independent.
2. Hardlink on the same filesystem without reflink support (for example ext4): no extra space; disc folder and source share the same file.
3. Verified copy otherwise, for example to another filesystem: each copy is read back and compared with the SHA-512 of the source data. That hash is reused for the checksum manifest, so copied files are not read a third time.

Attachments use a reflink or a verified copy, never a hardlink, so editing an attachment later does not change a finished disc folder. Before the first file is created, the destination is checked for enough space for files that may need a copy. Each run reports the logical bytes reflinked, hardlinked and copied; these are not physical SSD write counters. Permissions and modification times are preserved. With --iso, the disc tree is built in the workdir, the ISO is written from it, and the tree is removed afterwards.

The source is never changed before the final question. If creation fails or is cancelled before the disc is ready, create removes everything it created under the output; hardlinked disc files are only additional names of the source files. An abrupt process or power loss can leave a partial output behind; create then refuses that output directory until you remove it.

After a hardlinked disc is created and you keep the source (N), disc folder and source share their files. Editing such a source file in place also changes the disc folder, and burn then refuses the changed folder; create the disc again. Removing or renaming source files does not affect the disc folder.

Keep the selected files unchanged until creation finishes. create rechecks the selected units after the confirmation and compares the disc's payload before and after hashing, PAR2 creation and the final measurement. When removing units, it first checks every selected unit against the scan and removes nothing if one changed. Emptied grouping folders are removed as well, never the source itself.

What fits and what is supported

The payload, attachments, checksums, recovery data, README and filesystem overhead must all fit on one disc. Plans are measured with mkisofs -print-size using sparse stand-ins, without reading file contents. Creation checks the exact filesystem size again after recovery generation and after preparing the final folder, before manifest.json next to disc/ marks it ready for burning. With --iso, the completed ISO is checked again before publication. Capacity checks include growisofs's zero padding to a full 32-KiB write block.

Regular files and directories, including hidden entries and empty directories, are supported. Symbolic links, special files, and names containing line breaks are rejected. With recovery enabled, the disc needs at least one non-empty file.

Multiple hardlink names within the source tree, or between the source and an attachment, are rejected during the initial scan. The error lists the conflicting paths. A hardlink outside these trees does not cause rejection. Independent copies, including reflinks, are allowed.

Keep the source and output/workdir trees separate: neither may contain the other. Metadata-like names such as README.txt or .bd-archive are ordinary payload inside the source.

Compression, incrementals, packing, compression previews and automatic deferral by fill level require -m dar. Raw mode accepts -c none, but rejects --level even with -c none. The raw planning options --group-by, --order-by, --max-free and --attach require raw mode.

Read, verify and repair

Open the <name>/ folder from the mounted disc, or copy it with your file manager. This is a UDF + ISO9660/Rock Ridge data disc. Playback on standalone hardware depends on that player's data-disc and codec support.

The disc root contains a visible README.txt. It points to the hidden .bd-archive/ folder with the checksums and recovery files, because file managers often hide names starting with a dot.

Verify the prepared folder or the mounted disc root:

bd-archive verify /data/photos-2026-10/disc
bd-archive verify /mnt/disc

For a manual check of every manifest entry, run from the disc root:

sha512sum -c .bd-archive/checksums.sha512

To repair damage, copy the whole disc, including the hidden .bd-archive/ folder, to a writable directory. Change into that copied disc root:

cd /data/photos-disc-copy
chmod -R u+rwX .  # Only if the copy retained read-only permissions.
par2 repair -B. .bd-archive/recovery.par2
sha512sum -c .bd-archive/checksums.sha512

Repair changes the writable copy; it cannot repair a read-only optical disc. Without recovery files, hashes can identify corruption but cannot reconstruct lost bytes.

Older raw discs remain supported by verify:

• Discs with the source folder, checksums.sha512 and recovery.par2 at the root: use sha512sum -c checksums.sha512 and par2 repair -B. recovery.par2.
• Discs with root-level payload and .bd-archive/ metadata: use the same .bd-archive/ commands as above.

Next: Planning raw discs · Burning · On-disc layout