Why Backup Fragment Filenames Should Never Matter: Self-Describing Data Architecture

In naive backup designs, file recovery depends heavily on external metadata: strict directory hierarchies, exact file naming conventions (e.g., backup_part_001.dat), or separate database catalog files.

When disaster strikes 10 years later and files are pulled from various cloud folders, old USB drives, and email attachments, file systems routinely alter filenames. Windows might rename a file to backup_part_001 (1).dat, cloud sync engines might append conflict suffixes like [conflicted-copy], and operating system file pickers may flatten folder hierarchies entirely.

If a recovery tool requires exact filenames to reconstruct data, a simple filename change turns valid data into unrecoverable garbage.

---

The Fragility of External Metadata

[ Naive Backup Engine ] ──(Requires exact filename)──> Looks for "part_01.dat"
                                                              ▲
                                                    (File was renamed to:
                                                   "part_01 (1).dat" = FAILS)

External metadata is the most fragile layer of any storage medium:

• Filesystem Encoding Differences: Moving files between NTFS, APFS, ext4, and FAT32 often mangles UTF-8 characters and path delimiters.
• Automated Cloud Renaming: Cloud drives append numbers or timestamps when identical filenames collide.
• User Organization Errors: Users dragging fragments into a single folder accidentally overwrite or rename files.

---

The Solution: Self-Describing Cryptographic Headers

YourKeep solves this by embedding a comprehensive, self-contained Cryptographic Header directly inside the first bytes of every single .keep fragment file:

+-------------------------------------------------------------------------+
| Magic Bytes (0x594B454550 "YKEEP") | Format Version (0x01)              |
+-------------------------------------------------------------------------+
| Container UUID (128-bit)           | Chunk Index (k) / Total Chunks (N) |
+-------------------------------------------------------------------------+
| Threshold Quota (K)                | Master Payload SHA-256 Checksum    |
+-------------------------------------------------------------------------+
| AEAD Nonce (96-bit)                | GHASH Authentication Tag (128-bit) |
+-------------------------------------------------------------------------+
|                           Encrypted Data Shard                          |
+-------------------------------------------------------------------------+

How Stateless Recovery Works:

1. Filename Agnostic: You can rename all 10 fragments to random_a.xyz, movie.mp4, and photo.jpg and place them in a single flat directory.
2. Internal Magic Byte Parsing: The YourKeep recovery engine opens every file in the selected directory and inspects the binary header.
3. Automatic Grouping & Validation: The engine matches the Container UUID, identifies each fragment’s index $k$ and threshold $K$, verifies cryptographic tags, and executes Reed-Solomon reconstruction seamlessly.

---

Conclusion

True disaster resilience means building data containers that are completely self-describing. By eliminating external dependencies on filenames and directories, YourKeep guarantees that valid data remains recoverable under any operating system condition.