Two files can represent one memory

Do not delete a short video just because a nearby image appears to show the same scene. Apple’s Mac Photos export guide says an original-format Live Photo export produces separate still-image and video files. In that route, seeing two files is expected—not evidence of a duplicate.

The useful question is whether you retained the parts and behavior you wanted. A still picture that opens successfully does not demonstrate that the motion survived. Conversely, a video and an image sitting in a folder do not, by themselves, demonstrate that your next photo app will treat them as a single Live Photo.

The concrete export steps below concern Photos on Mac. If you use an iPhone, Windows or iCloud.com, record that route separately; do not assume its files or importer behavior match the Mac example.

Choose what you want to preserve before exporting

These goals can coexist. Keep preservation copies and convenience copies distinguishable instead of asking one export to prove everything. A folder called “sharing copies” is a useful organizational label; it is not a reason to remove the originals.

For a library-backup plan rather than a file export, follow Apple’s linked library-backup guidance from its iCloud Photos documentation. That page also explains that iCloud Photos content is not duplicated inside iCloud Backup. Do not count those two labels as independent copies of the same photo collection.

Make a small original-format export on Mac

Pick three non-sensitive Live Photos you recognize, including one whose edited appearance matters to you. Keep the source library intact. Before starting, allow room for the exported media and a second working copy; our space-planning guide explains why the number of thumbnails is not a capacity measurement.

1. In Photos on Mac, select the sample and use File → Export → Export Unmodified Original. This is the original-file route described by Apple, not a drag-and-drop test.
2. Record the app and macOS versions, selected items, export date and naming options. If you need assigned IPTC information and keywords, Apple provides an Export IPTC as XMP option. Keep any resulting sidecar files with the export.
3. Use a new destination folder. If a name collision or replacement prompt appears, stop rather than overwrite an earlier export. Wait for the operation to finish and record any error.
4. Keep that delivered set unchanged. Make a working copy for inspection, preserving its folder arrangement. Do not rename individual components or flatten several exports into one folder during this first review.

On iCloud.com, Apple documents separate original-format, high-resolution and compatibility-oriented download choices. Those labels answer different needs; “highest” does not make a choice interchangeable with an unmodified-original export. See the official download instructions for that route. Keep each route’s outputs separate until you understand the differences.

A download is not automatically independent of your everyday storage setup. Identify whether its destination is synchronized and which account or device is needed to retrieve it. The copy-map guide helps you record those dependencies without changing any settings.

Worked example: six files, but one component is missing

Fictional inventory, not an observed Apple export: you choose three Live Photos, labelled A, B and C for this example. Assume this particular original-format export should give you one still and one motion component for each. Excluding sidecars and extra versions, the expected media count is 3 × 2 = 6.

The observed total is also 2 + 1 + 3 = 6. Yet only five of the six expected original components are accounted for. C’s extra edited still conceals B’s missing motion file in the total.

The lesson is not that every export must have twice as many files as thumbnails. Sidecars, other media types and export choices change that arithmetic. It is that a total is not an item-by-item inventory. Record which components belong to each selected item, then investigate gaps. Similar names or adjacent positions are clues, not sufficient proof of a match when several exports are mixed.

If B is unresolved, keep both the source and the current export. Repeating only B into a fresh sample folder can help isolate what that route delivers. Do not “balance” the numbers by deleting an extra file or renaming a different video to match.

Check three different things: presence, contents and behavior

1. Presence: identify the source item and record every delivered component’s relative path. If you cannot establish the association, write “unresolved.” Do not invent a pair from filenames alone.
2. Contents: open the still in a trusted local viewer and play the video. Check that the scene is the expected one and note whether wanted motion and any expected audio are present. If a viewer cannot read a format, record that limitation; one app’s failure is not a diagnosis of file corruption.
3. Destination behavior: if the goal is to use another organizer, test working copies in a separate test library where the app supports that. Record whether it shows one motion-enabled item, two separate media items, or another result. Keep originals untouched if the result is not what you need.

A byte-for-byte copy check answers a fourth, narrower question. You can compare a delivered file with its plain copy using the local file checker, within its 32 MiB limit per file. Compare still to still and video to video—not still to video. A match cannot establish that both files belong to the same Live Photo or that an app will reconstruct it.

Do not rename extensions, convert the only copy or upload private media to an unknown repair website to make a failed test appear successful. Preserve the files and record the actual limitation first.

Keep a component ledger, not a “backup complete” badge

Download the blank component ledger

This original KYD text template is free to save, adapt and print for your own archive. Fill it out locally; the website does not receive your notes. Use private labels rather than sharing personal filenames, locations or account details in a public support request.

A useful conclusion is specific: “Still and motion components for A were retained; both opened locally; destination pairing not yet tested.” That record tells you what to do next. “Everything is backed up” hides the unfinished step.

Stop before deletion; finish the recovery route

This session is complete when the sample’s components and limitations are recorded—not when the phone has been emptied. A sample cannot establish that the rest of the library is complete. If a component is missing, an export fails or a destination drops behavior you need, retain the source and investigate that gap.

Apple documents that deleting from iCloud Photos is reflected across devices using that library. Do not use deletion as an experiment to prove independence. Continue with our non-destructive recovery drill to check retrieval from your intended backup location. If your next task concerns the JSON companions in a Google Photos export, use the Takeout context guide; its file relationships are a separate case, not a substitute for this Live Photo review.

Keep the JSON files while you check the export

Do not discard the JSON files just because your photos open without them. A viewable picture and a well-described picture are different preservation goals. Before tidying a Google Photos Takeout export, keep an untouched copy of the downloaded archives, retain the extracted folder structure, and investigate a small working sample.

This guide addresses one specific problem: an export contains unfamiliar JSON files, and old photos appear under a recent date. The aim is to decide what needs investigation before renaming, importing or rewriting anything—not to promise a one-click metadata repair.

Separate three kinds of information

Google’s download documentation distinguishes a timestamp assigned by the operating system during download from original timestamps inside the media. It also says additional information, such as Google Photos comments, is exported into secondary JSON files. That is not a claim that every exported image has every field you expect.

A column simply called “Date” is too ambiguous for a repair decision. Record its full label and the application. An absent field means not found in this inspection; it does not prove the picture was taken on the download date. Likewise, an old date in a filename is a clue, not independent proof of capture time.

Set up a working sample without flattening the archive

Google notes that a large export can arrive in several archives. Confirm that you have downloaded the parts listed for your export before treating a missing item as lost. Recent library changes may also fall outside an export’s contents. Record the export request and download dates so you know which snapshot you are reviewing.

1. Preserve the delivery. Keep the downloaded archive files unchanged. Do not rename or delete their contents as your first organizing step.
2. Separate extraction from experiments. Extract into a fresh, clearly named location. If a file conflict or overwrite prompt appears, stop and investigate instead of choosing “replace all.”
3. Copy a small working set. Choose an older camera photo, a screenshot or edited image, and a video. Keep their relative folders and candidate JSON files together. These cases can reveal different gaps.
4. Write down what you copied. Record the original relative path and archive part. Do not merge everything into a single folder: repeated filenames would become harder to distinguish.

My photo-export review/
  downloads-kept-unchanged/
  extracted-kept-unchanged/
  working-sample/
  review-notes.txt

This is KYD’s suggested local arrangement, not a representation of Google’s archive structure. Three folders on one drive do not make three independent backups. Use the capacity guide to allow for archives, extracted files and working copies, and keep a separate recovery copy where appropriate.

Worked example: one “wrong date,” three different decisions

Invented observations for teaching—not a test of a real Google account: someone downloaded an export on October 8, 2026. Their file manager shows that day for all three sample files. They then inspect the media and candidate companion data without changing either.

The three files look identical under one file-manager date column, but they call for three different actions. A bulk command that assigns that column’s date to every media file would erase the distinction the review just uncovered.

In this example, one item needs no demonstrated capture-date repair, one remains unresolved, and one needs a context-preservation decision. None of those outcomes authorizes deleting the source library.

Inspect one item without rewriting it

1. Open the media itself. Use a trusted local viewer and its information panel. Note the complete field label, value and application version. If the viewer exposes no suitable field, record “not shown” instead of inventing a date.
2. Inspect candidate JSON as text. Use a local plain-text viewer without saving changes. Do not upload family photos or metadata to an unknown online “fixer.” Names, descriptions and location-related fields may be private.
3. Establish the association. Keep the original path, compare identifying information that is actually present, and consult documentation for the specific export or importer. A similar basename alone is not enough when several files share it. Do not assume every JSON file describes one photo.
4. Test the destination with copies. If you intend to use a photo organizer, import only the sample into a separate test library where possible. Compare the displayed dates and wanted descriptions. Ask whether the importer supports this companion format; the presence of a JSON file does not establish support.
5. Write a bounded conclusion. For example: “Photo opens; capture date displayed; description not imported; original export retained.” This is more useful than “metadata fixed.”

If two displays disagree, preserve both values and their labels. A different timezone display is one possibility, not an automatic diagnosis. Do not apply a library-wide time offset until you know what each field and application represents.

When a cleanup or repair should stop

• Several possible companions: preserve them and mark the association unresolved. A rename based on a guess can make a later match harder.
• Unreadable archive or extraction error: resolve that problem before reviewing metadata. A partial extraction is not a trustworthy inventory.
• An importer skips context: keep the original media and companion data even if you create a convenient browsing copy elsewhere.
• A proposed repair overwrites originals: do not run it on your only export. First understand which fields it writes and test reversible copies.

The Library of Congress’s personal-archiving guidance emphasizes keeping descriptions with photographs. The practical point here is not to preserve a particular file extension for its own sake: preserve the information you would otherwise lose about the image.

A metadata edit may change a file’s bytes even if its visible picture does not change. Use our local file copy checker on an untouched source and a plain copy when the question is copy integrity; its limit is 32 MiB per file. It does not interpret JSON, determine a correct date, or verify an importer. See how to interpret a mismatch before labelling an edited derivative corrupt.

Keep a review record you can use later

Download the blank text worksheet

The worksheet is an original KYD template, not a Google export parser or a certificate. You may save, adapt and print it for your own archive. Fill it out locally; this website does not receive your notes. Keep completed records private and never include passwords or recovery codes.

Done for this session means: the delivered archives are retained, each inspected field is identified, ambiguous associations stay unresolved, and the next action is written down. Before relying on the export as a recovery copy, continue with the non-destructive recovery drill. Do not delete originals merely because three samples passed.

The question is not “Can I see the photo?”

A thumbnail is a useful starting point, not a recovery plan. The practical question is: if this phone disappeared, could I obtain a usable copy without it? A second question matters just as much: would that copy survive an accidental deletion in the app I use every day?

This guide uses a copy map to answer those questions. It is for personal photo libraries, not forensic recovery or business retention. Stop before deletion if the only available copy is on a failing device; repeated attempts to organize or rewrite it can make a recovery situation harder.

Start by choosing one small, non-sensitive sample: an older photo, a recent photo and a video. Do not delete those samples as a test. Their job is to reveal gaps before you change your library.

Draw the copy map before choosing a cleanup button

Label locations, not devices. Two folders on one laptop share that laptop’s failure risk. Two devices signed into the same synchronized library can share deletion behavior. A drive containing a deliberate export is a separate branch only if your synchronization or backup rules do not remove it when the working library changes.

Write down a simple test for each arrow: “Will a deletion here change the destination?” If you cannot answer from the service documentation and your settings, label the destination unknown. Do not count it as an independent copy yet.

Three actions that sound similar but do different things

These are different operations, not interchangeable instructions. Apple’s Optimize Storage keeps smaller device versions as needed while originals remain in iCloud. That helps device capacity but is not a separate archive. The official links below explain the service details; menus vary by app and OS version.

Worked example: a reassuring count that hides a gap

Hypothetical case: a family sees 8,400 items on the phone and 8,400 in the cloud. The matching total does not establish that all 8,400 are the same items, that videos play, or that an export contains the wanted originals. One omitted video and one duplicate image could leave the count unchanged.

1. Check a recent photo that should have uploaded after the last trip.
2. Check an old photo from a folder that was imported rather than captured by this phone.
3. Export a video, then play its beginning, middle and end from the export.
4. Record where the exported samples were opened and whether that location participates in sync.

If the imported folder is absent, the appropriate next task is to identify the missing scope—not to delete until counts happen to match. Google Photos exposes backup status and folder settings; those are useful checks, but the sample still needs to match the library you intend to preserve.

Leave with evidence, not a green badge

For each important group, record a location, the format you need, the export date and a successful opening check. Do not put account identifiers or private filenames into public support reports. A sample is deliberately limited: it can expose a problem, but cannot prove every item is recoverable.

Use the photo backup self-check to turn missing evidence into a next-action list. Then follow the non-destructive recovery drill. Neither tool grants permission to erase the source. Keep originals until you understand the remaining risks and have verified the copies you need.

A matching picture is not necessarily a matching file

To verify a plain file copy, compare its contents and then open the copy. These answer separate questions. Byte equality establishes that the selected contents match; opening checks whether a viewer can use them. Neither step inventories a whole photo library.

This guide includes a controlled experiment you can repeat without selecting personal files. We created five small SVG image files with precisely defined changes. You can inspect the source, download the exact bytes, compare the fingerprints and run the same pairs in the local checker.

Five files that expose four common assumptions

Original KYD SVG test graphics, not camera photos. The first two use identical drawing instructions; only their metadata differs. No third-party image is used.

The reference is a 640 × 400 geometric SVG with a small metadata value. It contains no scripts, external resources or private information. The exact copy retains every byte. One variant changes only the metadata value; another changes one color character. Both preserve the reference’s byte count. The truncated variant retains only the first 200 bytes.

We use five pairs, including the deliberately broken file against itself. Expected outcomes follow from the construction of the files, not from trusting the checker’s verdict:

The important contrast: the metadata-only variant keeps the drawing instructions unchanged but must fail a byte-equality test. Meanwhile, two copies of the truncated input must pass that test despite having incomplete image markup. “Different” does not diagnose corruption, and “identical” does not certify image health.

What the browser actually showed on October 15

We ran all five case buttons in the Codex in-app browser on Windows against a local preview of this build. Each calculation matched the expected outcome and both Node-generated reference hashes. These are recorded software observations, not a test of a reader’s photo library or a third-party certification.

We also selected the generated reference and exact-copy files through the ordinary file pickers, then changed the second selection to the metadata variant. The first pair matched and the second differed. Changing a selection hid the old result; clearing disabled report saving. No-selection validation and the original text demo passed.

The three preview images loaded at 640 × 400 intrinsic pixels. The reference and metadata variant looked the same, while the color variant differed. Opening the 200-byte truncated SVG directly produced an XML parsing error. That observation makes the last row important: two matching invalid files are not evidence of a usable photo.

Boundaries: this was one browser environment. The file-picker test used generated local files, not a browser download-and-reselect round trip. It does not establish mobile-device compatibility or behavior for camera formats. Read the machine-readable observation record and repeat the experiment yourself.

Repeat the experiment with or without downloading

Route A: run the built-in image cases

1. Open the image-file experiment. Choose one of the five named case buttons.
2. Read the pair names, byte counts, computed result and reference-check message. The page calculates the result from embedded copies of the same public fixture bytes; it does not read your selected personal files.
3. Expand the fingerprints and compare them with the published reference list. Run the broken-input pair as well as the successful-copy pair.

Route B: repeat through the ordinary file pickers

Download the reference and the variant you want below. Use the download links, not “save webpage,” which may wrap or rewrite a document. If your browser opens the SVG instead, save the linked file without editing its contents. First check its byte count and fingerprint.

• reference.svg — 458 bytes. Original geometric test chart.
• identical-copy.svg — 458 bytes. Exact copy; only the filename is different.
• metadata-change.svg — 458 bytes. One metadata byte changed. Drawing instructions unchanged.
• visible-change.svg — 458 bytes. One color byte changed; same byte count, different drawing.
• truncated.svg — 200 bytes. Only the first 200 bytes retained; deliberately incomplete XML.

Download SHA-256 reference list · Machine-readable manifest

1. In the checker’s File A field, select the downloaded reference. In File B, select a variant.
2. Choose Compare files. Compare the observed size, result and hashes with the table and reference list.
3. For the last case, select truncated.svg in both fields. Expect byte equality, not a repaired image.
4. If a result differs from the reference, stop. Check whether you saved the SVG file itself or a browser-generated HTML page, then download a fresh copy. Do not experiment on your only personal original.

The fixtures are original KYD teaching files. You may reuse, modify and redistribute them for testing with attribution to this guide; clearly label modified versions. A reference hash supplied by the same publisher is useful for detecting an altered download, not independent proof that the publisher is trustworthy.

Check the reference without this website’s calculator

For example, in PowerShell opened in your downloaded sample folder, this read-only command prints a SHA-256 digest:

Get-FileHash -Algorithm SHA256 -LiteralPath ./reference.svg

The expected reference size is 458 bytes, and its SHA-256 is:

e07762ee42804677d7ebefe867a4fda1a75ab24202c83b00f2cf0a60ff69cf5c

Uppercase versus lowercase hexadecimal letters do not change the digest. Reference hashes were generated using Node’s crypto implementation, separately from the browser’s Web Crypto calculation. The fixture generator documents every change.

Now compare a real copy without changing the source

Choose a source that is already readable and locally available, then make an ordinary copy into a new folder. Wait until copying finishes. Do not overwrite a previous backup during this test. Compare the source with that copy, not an original with a resized sharing export.

Apple documents multiple ways to archive or copy iCloud information. Record which export route you used. An unmodified-original download and a rendered or converted version are different comparison targets. Keeping both may meet your needs better than declaring one corrupt.

A short mismatch investigation

1. Confirm the target. Are you checking a plain copy, an edited derivative or a cloud export? Write that down before interpreting the result.
2. Check local availability. A cloud-backed picker may download an item before the tool reads it. Choose files already stored locally if you want to isolate a disk-to-disk copy check.
3. Repeat narrowly. Copy one readable source into a fresh folder. Compare that pair. If it matches but an earlier export differs, investigate the export settings rather than blaming the copying method.
4. Preserve an unresolved result. Keep both files and a private note of the workflow. Do not rename a variant over the source to make a discrepancy disappear.
5. Stop on hardware symptoms. If a drive disconnects or repeatedly reports read errors, stop repeated experiments and seek suitable recovery assistance. This browser tool cannot diagnose or repair a drive.

Saving the checker’s text result omits filenames but includes fingerprints and sizes; keep it private. The new on-screen next step depends on the actual result, including a warning for empty matching inputs. It is not a “safe to delete” instruction.

The small text self-test is still available

The original Try known demo button compares the UTF-8 bytes of abc against abc, then against abd. The first pair matches and the second differs despite both being three bytes. The SHA-256 reference for abc, with no newline, is:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

This is a useful quick self-test. The image fixtures add the distinction that a byte-level test cannot infer whether the drawing changed or the file still decodes. A text-only self-test did not establish those viewer outcomes.

What remains outside the experiment

The checker reads the selected bytes in memory, compares them directly and separately calculates SHA-256. It does not upload, decode, repair, scan for malware or delete files. MDN notes that the browser digest API needs the whole input in memory and a secure context; the 32 MiB-per-file limit is intentional.

One successful pair is not a complete-library audit. Our experiment does not check album membership, original capture dates, cloud account access or Live Photo pairing. For motion components, continue with the Live Photo component guide. For a collection, use an appropriate batch inventory and verification workflow rather than extrapolating from one pair.

After checking copies, follow the non-destructive recovery drill to test retrieval from the destination you intend to rely on. Preserve your originals until the wider plan is verified.

Measure the files you intend to preserve

“Ten thousand photos” is not a capacity measurement. The space needed by ten thousand small screenshots is different from that of a mixed library containing RAW photographs and long videos. Start with the byte size of the files you actually plan to copy.

This planner budgets a new, full copy on one destination. It is not a subscription recommendation or a prediction of phone storage. If a destination already contains part of the same archive, do not blindly add the full library again: first establish what exists and what your backup software will retain. Do not delete that existing copy to make the estimate fit.

Use exported-file sizes where possible. Optimized phone storage or a compressed cloud collection may not represent the size of the originals you want to keep. Export a manageable sample, check its format, then measure the actual collection when feasible.

Make the assumptions visible

Reserve is a chosen planning allowance, not a manufacturer requirement. In this model it is a fraction of the total allocated space budget. A 20% reserve therefore means dividing by 0.8, not simply adding 20% to the data amount.

“Extra retained versions” means additional old or changed files kept alongside the current archive. Enter zero if you are planning only one full version, but recognize that doing so does not budget version history. Software that retains multiple full snapshots could need much more space; this simple model does not simulate deduplication or compression.

Worked case: 120 GB today, a year of growth

Hypothetical inputs, not a measured user library: 120 GB current archive, 4 GB of net additions per month, 12 months, 30 GB of extra retained versions, and a 20% reserve.

1. Growth: 4 × 12 = 48 GB.
2. Future archive plus versions: 120 + 48 + 30 = 198 GB.
3. Total budget: 198 ÷ 0.8 = 247.5 GB.
4. If the intended destination reports 200 GB of free space, the gap is 47.5 GB.

The answer is not “buy the next advertised size.” Compare with usable free space after formatting and other stored files. If you intend two independent destinations, each needs its own suitable budget; two copies competing for the same free space do not create two independent devices.

Run these numbers in the backup space planner. It also doubles only your growth assumption for a sensitivity check: 120 + 8 × 12 + 30 = 246 GB of data, requiring 307.5 GB with the same reserve. The 60 GB difference shows why a small change in monthly capture habits can matter more than rounding a current reading.

Keep GB and GiB separate

This tool uses decimal GB: 1 GB = 1,000,000,000 bytes. A GiB is 1,073,741,824 bytes. Consequently, 247.5 GB is about 230.5 GiB. These are two unit labels for the same number of bytes, not evidence that files disappeared.

If a file manager reports GiB, use the unit-conversion field before entering capacity numbers. If its label is ambiguous, prefer an exact byte count or the operating system’s documentation. Mixing a decimal budget with a binary free-space reading can produce a false shortage or surplus.

Replace the estimate with observations

Write down the collection size and the date at two comparable points. Net additions divided by elapsed months give a starting growth estimate. A month with an overseas trip or a video project may not represent the rest of the year; test a higher-growth scenario separately.

Revisit the plan after changing camera quality, adding RAW files, keeping edited copies or changing retention settings. A plan can be arithmetically correct and operationally wrong if those assumptions change. Space is only one part of a backup: finish by checking copy integrity and whether you can actually retrieve the files.

Test retrieval, not your luck

A backup routine ends with an observation: the copied material can be retrieved and used. This drill is designed to produce that observation without wiping a device, emptying a trash folder or disconnecting an account. It is a planning method developed for this site, not a claim that KYD has tested your hardware or cloud subscription.

Set aside a short, uninterrupted session. Use a small sample first, retain the originals, and create a new destination folder that is not part of your photo synchronization. Do not change live retention settings to perform the exercise.

Choose a sample that can reveal different failures

This is a targeted sample, not a statistical certificate. Add personally important material that would be costly or impossible to replace. Keep that list private; no one needs to know the contents for you to use the worksheet.

Run the drill without deleting the source

1. State the route. For example: “Retrieve an exported copy from the external drive into a new test folder.” Do not just write “backup works.”
2. Retrieve. Copy the sample out of the backup location. Use the provider’s documented export route for cloud material. Note the account or device dependency privately without recording credentials.
3. Open locally. After retrieval completes, open the downloaded files from the test folder, not from a link in the cloud app. If testing offline access, disconnect only after downloads finish and only if doing so will not interrupt other work.
4. Inspect. Check content, dimensions, video playback and special-format components. For a plain, unmodified file copy within the 32 MiB limit, also use the local byte comparison.
5. Record and retain. Keep a short result, date and next action. Leave the originals and the backup unchanged.

The export route matters. Apple documents separate ways to copy originals and notes limitations for Shared Albums. Google’s folder and item backup checks help identify what entered a cloud library. Neither substitutes for opening your own retrieved sample.

Use a record that separates facts from assumptions

Print this page or use your own private note. A filename can reveal a person, event or location; store the sheet where you would store other private backup records. Do not attach it unredacted to a public issue.

Example record: “October 7: three synthetic test files copied into a separate folder; contents compared. No cloud export, photo decoding or full-library recovery tested.” This is the kind of limited statement a software test can support. It would be misleading to rewrite it as “all photos are safe.”

Stop when a result is ambiguous

• A sample is missing: identify the missing folder or date range before any cleanup.
• A file opens only online: establish whether you saved a placeholder, a link or the complete file.
• A hash differs: check for conversion or editing; do not label the original corrupt from that result alone.
• A copy needs the same unavailable account: your recovery dependency remains unresolved.
• The drive disconnects, reports errors or is physically failing: stop repeated experiments and seek appropriate recovery help.

Schedule your own next check after a major library move, export-setting change or new storage device. There is no universal interval that proves safety. The value comes from noticing when your assumptions no longer match the actual retrieval path.

Return to the backup self-check to identify unfinished checks, or to the copy map if the independence of your copies is unclear.