# Is there loss of metadata during backup? **URL:** \ **Category:** Development\ **Tags:** media-records, metadata, data-recovery\ **Created:** [October 31, 2026, 12:00pm UTC](https://gramps.discourse.group/t/is-there-loss-of-metadata-during-backup/10173 "2026-10-31T12:00:48Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\ **Post date:** [October 31, 2026, 12:00pm UTC](https://gramps.discourse.group/t/is-there-loss-of-metadata-during-backup/10173/1 "2026-10-31T12:00:48Z")
Gramps recognizes that Media objects may have metadata sidecars. But does it gather up sidecars during exports? Or is that a dataloss during export? ---
**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\ **Post date:** [October 31, 2026, 12:28pm UTC](https://gramps.discourse.group/t/is-there-loss-of-metadata-during-backup/10173/2 "2026-10-31T12:28:44Z")
And there can be multiple sidecars for Media object. Besides the embedded metadata (that naturally travels within the media object), Media objects might have one (or more) sidecar that matches the media object filename but with a different extension… such as the `.xmp` file extension. But there can also be indexed sidecars that are indices of files in the folder. Like the hidden Picasa ~~`.picasa.xmp`~~ `.picasa.ini` file in XMP format. That has the complication that the Gramps export might not have all the indexed files attached as Media objects. Filtered exports increase the likelihood that some of the sidecar listings won’t be valid when the backup file is restored. ---
**Author:** ![stuck](https://avatars.discourse-cdn.com/v4/letter/s/90ced4/32.png) [@stuck](https://gramps.discourse.group/u/stuck)\ **Post date:** [October 31, 2026, 12:54pm UTC](https://gramps.discourse.group/t/is-there-loss-of-metadata-during-backup/10173/3 "2026-10-31T12:54:18Z")
> [@emyoulation](#): > > Like the hidden Picasa `.picasa.xmp` file Is that file something that Gramps creates? The only hidden .picasa files I’ve ever seen are all called `.picasa.ini` (one per folder). ---
**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\ **Post date:** [October 31, 2026, 1:00pm UTC](https://gramps.discourse.group/t/is-there-loss-of-metadata-during-backup/10173/4 "2026-10-31T13:00:04Z")
You’re right. Working from memory at my age is fraught with dangers. ---
**Author:** ![emyoulation](https://yyz2.discourse-cdn.com/free1/user_avatar/gramps.discourse.group/emyoulation/32/67_2.png) [@emyoulation](https://gramps.discourse.group/u/emyoulation)\ **Post date:** [October 31, 2026, 2:49pm UTC](https://gramps.discourse.group/t/is-there-loss-of-metadata-during-backup/10173/5 "2026-10-31T14:49:17Z")
> asked Gemini to assess the Gramps approach, suggesting comparison of its Media data stucture to an amalgamated metadata database **Yes, conceptually, Gramps operates very much like an internalized, highly structured “amalgamated metadata sidecar,”** though with a major architectural twist: instead of sitting _beside_ your files as individual companion files (like `.xmp` or `.picasa.ini`), Gramps pulls all that relational metadata into a centralized database (SQLite or BSDDB) while leaving your raw media files completely untouched on your hard drive. Comparing how Gramps handles media management to traditional sidecar systems highlights several key similarities and differences: * * * ### 1. How Gramps Parallels a Sidecar System - **Decoupling Metadata from the Master File:** Just like a sidecar file prevents you from having to bake edits, tags, or copyright data directly into a raw photo or document, Gramps keeps your master image, PDF, or audio files pure and unmodified. - **The “MetaMedia” Layer:** Gramps creates an internal “Media Object” record for every file you link. This record acts as a virtual container holding titles, dates, author info, notes, source citations, and bounding-box crop/region-of-interest markers (such as pointing out a specific person’s face in a group photo). This is conceptually identical to the data stored inside a `.picasa.ini` or `.xmp` file. - **Path and Checksum Tracking:** Traditional sidecars rely on matching filenames to stay tethered to their assets. Gramps maintains absolute or relative file paths coupled with digital **checksums**. This allows Gramps to track your media even if you move or rename the underlying files—acting like a smart, self-healing sidecar index. ### 2. Where Gramps Differs from Traditional Sidecars While standard sidecars are _file-based_ and decentralized (one `.xmp` per photo, or one `.picasa.ini` per folder), Gramps treats media metadata as part of an **interconnected relational graph** : - **Many-to-Many Mapping:** A sidecar file belongs strictly to one file or one folder. In Gramps, a single media object (e.g., a 19th-century census manifest) can be linked simultaneously to multiple people, events, places, and sources without duplicating the metadata or the file itself. - **Database Amalgamation:** Instead of scattering thousands of `.xmp` files across your hard drive, Gramps aggregates all media metadata into your family tree database file (or packages them together only when you explicitly export a `.gpkg` archive). - **Genealogical Depth:** Standard sidecars track technical data, tags, and cropping coordinates. Gramps extends this “sidecar” concept into deep historical provenance—linking media directly to _citations_ that prove _why_ a specific document validates a genealogical claim. ### Summary If traditional sidecars are decentralized sticky notes attached to individual files, Gramps functions as an **amalgamated, master metadata ledger**. It virtualizes the sidecar concept, pulling all descriptive, relational, and historical data into a unified database while using file paths and checksums to keep an arm’s-length connection to your actual media library.