Protecting the library itself

Your index, your settings and your corrections are work too. This is what Photo Date Rescue does to keep them safe — and, in the same plain words, what it does not.

Applies to: Photo Date Rescue for Windows, version 3.0.4. Last verified: 28 July 2026. Every statement on this page was checked against the shipping 3.0.4 build — both the source and the packaged bundles — and deliberately not against our own feature list. If you are on an older or newer version, the behavior may differ; check What’s new for changes.

This page is the reference we cite from our comparison table. Each capability below has its own permanent link, so a claim about PDR can always be traced to the paragraph that supports it. Where the honest answer is “no” or “only partly”, this page says so in the same words the comparison uses. We would rather publish a limitation about ourselves than a strength we cannot stand behind.

This page is deliberately not about backups. Whether a second copy of your photos exists somewhere else is a different question, and it has its own page at Backing up. What follows is narrower and less comfortable: whether the working library resists damage in ordinary, everyday use.

It is worth saying up front that this is the task PDR scores worst on, and we have published it anyway. PDR is a repair tool. Its whole purpose is to change your files — to write correct dates into photos that have the wrong ones. A tool built to write is never going to win a category that rewards leaving things alone, and several answers below are “no” for exactly that reason rather than through neglect. Where the “no” is genuine neglect, we say that too.

At a glance

The first seven questions below are the ones the comparison table asks of every product, PDR included. They were written before any product was examined.

Question	PDR 3.0.4
Are my original files left alone?	Yes — the correction is written to a copy, never the source
Does PDR check its own index for damage?	No — no check of any kind runs
Can a damaged index be rebuilt without losing my work?	Partly — a rebuild keeps your names and albums, but loses who is in which photo
Does it survive a crash or a power cut?	Partly — the library survives; the last few changes may not
Can I export my settings and take them with me?	No — there is no export at all
Does it notice files changed outside PDR?	No — changed files go unnoticed, missing ones are dropped in silence
Does it record what it changed, and when?	Partly — it records it; 3.0.4 gives you no way to read it
Can I go back to several earlier states of the library, not just the most recent copy?	Partly — several restore points, but some are duplicates and the dates shown are wrong
Can I undo a whole saved batch of date corrections in one step?	No — nothing undoes a saved batch; restoring a backup is the only way back
Am I stopped before two computers damage one portable library?	No — the second machine is labeled read-only but can still write
Can I see what is inside a backup before I restore it?	Partly — the recovery routes count it; the everyday list shows a size and an unreliable date

Whether your original files are left alone

They are, and it is not optional. A Fix run never writes to the photo you pointed it at. It copies each file into your library folder first, and the corrected date is written into that copy. The source file is opened for reading and nothing else: it is not rewritten, not renamed, not moved and not deleted. There is no in-place mode and no setting that turns one on, so leaving your originals alone is not a preference you can get wrong.

This is the whole shape of the product, so it is worth being concrete about what you end up with. Your source folder is exactly as it was. Alongside it, in the library folder you chose, there is a new copy carrying the right date, renamed to a date-ordered filename. PDR keeps a record of what that file used to be called, so the original name is not lost either.

Two consequences follow. The first is that a Fix run costs disk space, because a corrected photo is an additional file rather than a changed one. The second is that the correction is written into the copy's own metadata rather than held in a private database, so it travels with the photo — move that copy to another machine, or open it in another program, and the right date is simply there.

Indexing, browsing and searching write nothing at all, to originals or copies.

Limitations

Videos get no metadata write. The copy is placed and renamed by date, and the date is recorded in the index, but no timestamp is written inside the video file itself. Move that copy somewhere PDR is not running and the date lives only in its filename.
HEIC and RAW copies get EXIF dates but no XMP date. Some programs read only the XMP date, and for those the copy will still look undated. This is a known gap rather than a decision.
The copy's own modified time is the time it was copied — not the capture date. A photo taken in January 2020 and fixed in May 2026 carries a 2020 date inside the file and a 2026 modified time outside it, so sorting a folder by “date modified” in Windows Explorer will not show you the photo dates.
There is one place PDR will overwrite a file, and it is not a source photo. In the viewer, an enhanced image can be saved either as a new file or over the top of the one you were viewing. The default is a new file, and the file at risk is the library copy, never the original you imported.

Whether PDR checks its own index for damage

It does not. There is no integrity check anywhere in 3.0.4 — not on startup, not on a schedule, and not on demand. PDR never asks the database whether it is healthy, and it has no way to tell you that it is not.

This is a real gap rather than a design trade-off, and we are not going to dress it up. The database engine PDR uses offers a built-in consistency check that most applications run occasionally; PDR does not call it. If the index were damaged — by a failing disk, say — the first you would know is that searches started returning the wrong thing, or nothing.

What follows from that matters for the next section. Because nothing detects damage, nothing can prompt you to fix it. The repair described below is real and it works, but you have to decide to run it yourself, on a hunch.

Rebuilding a damaged index

There is a rebuild, and it costs you more than time. PDR can walk your library folders again and reconstruct the index from what it finds. The people you have named, the albums you have made and the family trees you have saved do survive, because they live in separate tables. What does not survive is the links between them and your photos. Face matches, AI tags and album membership are attached to the file entries, so when stale file entries are cleared those links go with them — and a rebuild only puts back the files it finds missing. It cannot reattach what was already deleted. So you get your photos and your list of people, and not the knowledge of who is in which photo.

If you want everything back rather than most of it, restore a dated copy instead of rebuilding. That is the route that keeps the connections.

You are also not relying on the rebuild, because PDR keeps dated copies of the index without being asked. A copy is taken every time PDR starts, before the live index is opened. They are not simply overwritten: PDR keeps the last five launches, then promotes older ones so that one survives per day for a week and one per week for a month.

Read the number of files as an upper bound, not as the number of points you can go back to. We counted and fingerprinted every copy on the machine we test against. There were thirteen launch copies — and only eight distinct states among them. Six of the thirteen, spanning three days and five separate launches, were byte-for-byte identical. The reason is the same defect described further down this section: the ladder sorts and buckets copies by their modification time, and that time is inherited from the library rather than set when the copy is taken. So launches that found the library unchanged produce identical files that all land in one day’s bucket. The ladder is real and it is worth having; it simply holds fewer genuinely different states than the count of files suggests.

Those copies are not free, and the total is larger than the launch ladder alone. On the same machine — a real library of around forty thousand photos, with an index of about 370 MB — the backup folder held 7.9 GB: 4.8 GB of launch copies, 3.3 GB of the automatic People copies described below, and one 49 MB leftover. All of it sits on your system drive, quietly, without ever asking. If your system drive is small, that is the number to know.

Two more kinds are taken on top of those, and here we have to correct ourselves. PDR does take a copy of its own accord before certain actions — but only four of them, and all four are in People: before Improve Recognition for one person, before Improve Recognition for everyone, before sending a person back to Unnamed, and before re-clustering faces. That is the whole list. No automatic copy is taken before a Fix run, before a rebuild, before an organizing pass or before a restore. If you want a copy before one of those, you have to take it yourself, from Settings › Backup — you can give it a name and keep it, and copies you take by hand are never removed automatically, because they are yours to manage.

Those four People copies have a ceiling of ten, and the ceiling is only applied at the moment an eleventh is taken. Nothing ages them out. On our test machine ten of them, all made during a single afternoon in June, were still on the drive fifty-four days later, occupying 3.3 GB, because no further People action had been run since. They are not doing any harm and they are genuinely useful copies — but if you are looking at a large backup folder and wondering what is in it, this is usually the answer, and deleting the older ones from Settings › Backup is safe.

One more thing worth knowing if you are auditing the folder yourself: a copy left behind by an earlier restore is named differently from everything above, and PDR does not recognize the name. It is therefore not shown in Settings › Backup and no housekeeping will ever remove it. It is a perfectly good copy of your index and can be restored by hand, but you have to know it is there. Ours was 49 MB and seventy-one days old.

Where they live matters more than it sounds. These copies are written to PDR’s own application-data folder on your system drive, not to your photo drive, so they are there whether or not your library drive is attached — including in the case described under files changed outside PDR, where starting PDR without the drive drops those entries from the index. Settings › Backup lists every copy and restores any one of them.

The date shown against each copy is not the date the copy was taken, and we had this wrong. The list reports the file’s modification time, and on Windows copying a file carries the original’s modification time across with it — so what you are shown is the last time your library changed, not the moment the copy was made. Re-measured 30 July 2026, and it is worse than the three copies we first reported: on our own machine six consecutive copies — created by five separate launches across three calendar days — are all listed under one identical date, one identical time and one identical size, and they are byte-for-byte identical files. A seventh is dated a day and a half before the launch that created it. Until this is fixed, do not use the dates in that list to decide how far back you are going. Take copies by hand and name them, because the name is the only field that tells you the truth.

Separately from all of that, PDR mirrors the index, the correction log and the most recent copies into a .pdr folder on the library drive when the drive is attached. This mirror is a portability feature and a safety net at once. PDR rewrites the mirror about every thirty seconds while you work, and it does so using the database’s own consistent-copy mechanism rather than a plain file copy, so it is a sound backup and not a snapshot of a half-written file. Restoring from it replaces your index wholesale, and the app’s own confirmation says what that means: your faces, names, dates and trees are back. Two conditions apply — it only exists if your library lives on an external drive or NAS you connected as your Library Drive, and restoring from it asks for your license key.

The limits, stated plainly. Restoring is a replace rather than a merge: the copy you choose becomes the index, so anything you did after it was taken is gone. The rebuild reconstructs the index from your files, so anything that only ever existed in the index and has no counterpart on disk is rebuilt by PDR rather than recovered. And because nothing checks the index for damage, PDR cannot tell you the index is broken.

You do not have to spot the problem yourself. PDR raises it on the dashboard. If it finds photos on disk that are missing from the index it offers Refresh now, and if the copy on your library drive holds substantially more than the index does it offers Restore now. What is fair to say is that both cards can be dismissed for good, and neither is a damage check — they notice a gap in the counts, not corruption.

Detaching your library drive does not leave you unprotected. The launch and pre-change copies described above are held on your system drive, not beside your library, so they are unaffected when the external drive is disconnected. Only the continuously rewritten mirror lives on the library drive. The same answer is recorded on our comparison table.

Seeing what is inside a backup before you restore it

It depends which of the three restore routes you are on, and the everyday one is the weakest. Restoring from Settings › Backup tells you the file name, when it was taken and how big it is, and warns you plainly that everything since then will be lost — but it does not tell you how many photos, albums or names are inside it. Size and date are your only clue, and the date is not reliable. The two recovery routes are better: both open the backup, count what is in it, and put those numbers in front of you before you agree to anything.

To do it

For an everyday restore, open Settings › Backup and read the date, size and any name you gave the snapshot. Use the name — it is the only description of contents that will ever exist for that copy. See rebuilding a damaged index.
If PDR notices the copy stored beside your library holds more than PDR is currently showing, it says so on the dashboard and gives you the two numbers — how many photos and album memberships the backup holds against how many are indexed now — before offering Restore now.
If you point PDR at a drive that already contains a library, the Existing PDR library found screen reports the database size, whether an edit history is present and which machine wrote to it last, before you press Restore from this library. It also shows a count of recent snapshots stored beside your library. In 3.0.4 that count always reads zero, because the step that copies snapshots to the library drive looks for file names PDR never writes. Ignore that figure; the other three are real.

Limitations

The Settings list shows no counts at all. Not the backup’s, not the live library’s. Two snapshots of similar size are indistinguishable unless you named them.
And the date beside each one can be wrong. It is the file’s modification time, which a copy inherits from your library rather than taking from the clock, so copies made hours or days apart can be listed under the same date — see rebuilding a damaged index. That removes the second of the two clues, which is why we now grade this row “partly” on the strength of the two recovery routes alone.
Copies from older versions of PDR are recognized. The older naming scheme is understood, so those copies do appear in the list — shown as ordinary launch copies with no name against them.
You cannot browse a backup. There is no way to look inside one and pull out a single album, a single person or a single date correction. Restoring is all-or-nothing.
Name your manual snapshots. The name is the only thing that makes one recognizable later, and it is optional, so it is easy to end up with a list of dates that mean nothing.

Surviving a crash or a power cut

The library should survive; the last few moments of work might not. PDR runs its database in write-ahead logging mode, which is the arrangement that keeps a database consistent when the program dies unexpectedly. Referential integrity is enforced rather than assumed, and PDR settles the write-ahead log properly when it shuts down, so a clean quit leaves nothing dangling.

If PDR itself crashes — the application quits, the machine keeps running — the index should be intact when you reopen it, with everything committed up to the crash.

A power cut is a weaker story and we would rather say so than let you assume otherwise. PDR runs the database at a durability setting that does not force the operating system to flush every change to the disk platter immediately. That choice buys a great deal of speed while indexing tens of thousands of files, and it does not risk corrupting the database. What it does risk is losing the most recent committed changes when the power goes rather than the program. In practice: the library is fine, the last handful of things you did may be gone.

We have not published a figure for how much can be lost, because it depends on your disk and your operating system, and we have not measured it. Rather than guess, we are telling you the setting and its consequence.

Two interruptions that are easy to get wrong are handled deliberately. Restoring an earlier copy of the index clears the database’s pending write-ahead files as part of the restore; without that step the old pending writes can be replayed over the copy you just restored and quietly undo it. And the startup pass that can remove index entries takes a copy of the index before it touches a single row, so an interrupted or misbehaving tidy-up leaves the previous state recoverable from Settings › Backup.

One qualification on that copy, which we should have stated the first time. It is taken before the database is opened, and it copies the main index file only — not the pending write-ahead file beside it. After a clean quit that makes no difference, because quitting folds the pending writes into the index. After a crash it does: the pending file still holds committed work, PDR replays it into the live index a moment later and your library is whole, but the copy taken on that launch was made a moment too early and is behind by whatever the crash left pending. The library survives. The safety copy of it is the thing that loses the last few moments, and the first restart after a crash is the worst moment to reach for it.

Taking your settings somewhere else

You cannot. Version 3.0.4 has no export and no import of settings, folder rules, naming schemes or presets of any kind. There is no file to copy and no menu item to look for. Moving to a new computer means setting PDR up again by hand.

This is a straightforward missing feature, not a considered position. It is on the list.

One clarification so the boundary is honest, because it is easy to confuse the two. Your index can travel: PDR keeps a copy alongside your library so that a library moved to a new machine can be picked up rather than rebuilt from nothing. That mechanism is described on the restoring page, and it is about the library. It does nothing for your preferences, which stay behind.

When files change outside PDR

This is the most important section on the page, and the one most likely to surprise you.

PDR notices files that have disappeared. It does not notice files that have changed. Each time it starts, PDR walks every entry in its index and checks whether that file is still where it was. What it never does is compare modification times or contents, so a photo that another program has edited, rotated or re-saved looks completely unchanged to PDR. The index quietly goes stale and nothing says so.

For files that have gone, the behavior is worse than silence. PDR does not report them and ask you what to do — it removes them from the index. And it has no way to tell the difference between a photo you deleted and a photo sitting on a drive you happened to unplug. Both look identical to the check it performs.

The practical consequence, stated as plainly as we can manage: if you start PDR while your photo drive is disconnected, the photos on that drive are dropped from the index. Your photos are untouched — nothing is deleted from the drive, and the drive itself is never written to — but PDR will no longer list or search them. Reattach the drive and rebuild the index and the photos come back, because the index is reconstructed from the files themselves.

What does not come back is what PDR knew about them. Face matches, AI tags and album membership hang off the index entries, so they are cleared along with them and a rebuild cannot put them back — it finds the files again, not the knowledge. Your named people and your albums still exist; which photos they contain does not. So the rebuild is the recovery of last resort here, not the tidy answer we implied. If you have a copy of the index from a launch when the drive was attached, restore that instead: see rebuilding a damaged index.

The safest habit is simply to attach the drive before you open PDR. We would rather tell you that than have you discover it. If it has already happened, you have two ways back: reattach the drive and rebuild, or — better — restore the copy of the index taken at the previous launch from Settings › Backup, which is the route that keeps the face matches and album membership. See rebuilding a damaged index. The underlying behavior is listed in known gaps, and our own view is that entries for a drive that is merely absent should be marked unavailable rather than removed.

A record of what was changed, and when

In 3.0.4 there is no such record.

PDR contains the machinery for one: a routine that appends every date correction to date-corrections.log.jsonl in its application-data folder, one line per correction, stamped with the time. It is append-only by design, so entries could never be quietly rewritten. Alongside it sits an undo for the last correction.

None of it runs. The routine is only reached from a code path that no control in the application calls, so the log file is never created and the undo beside it never fires. There is no history panel, no log viewer, and no file to open even if you went looking for it. The machinery was built and never connected.

What you do get is narrower and lives elsewhere: the Undo panel in Needs dates, which reverses the last batch of dates you set for about a minute after you set it, and the library copies taken at each launch, which let you go back to how the library looked at a point in time. Neither is a per-change history.

We have graded this “no” on the comparison table for that reason. Connecting the log and giving it a viewer is on the list below.

Reversing a whole batch of saved date corrections

Yes, for about a minute. When you set a date on a selection in Needs dates, it is written to your library straight away — there is no staging step. A small panel then appears at the top of the view reading Saved N files, with an Undo next to it. Press it and every file in that batch goes back to the date, source and confidence it had before, and returns to the Needs dates list. The panel disappears roughly sixty seconds after the save, and once it has gone there is no other control that takes the batch back.

To do it

Open Needs dates, select the files that share a date, and set it.
If any of them already had a date, PDR asks you to confirm before replacing it.
Read the Saved N files panel at the top of the view. If the batch is wrong, press Undo while it is still showing.
If the panel has gone and you still want the batch reversed, open Settings › Backup and restore a copy taken before you started — accepting what else that costs you. See rebuilding a damaged index.

Limitations

The undo covers the last save only. Save a second batch and the first one is no longer reachable, however recent it was.
It expires on a timer, not on your attention. Roughly sixty seconds after the save the panel dismisses itself. Leaving the view or dismissing the panel by hand ends it early.
There is no history of saves. No list, no log viewer, nothing that shows you which batches you set last week.
Restoring a copy is not selective. The copy you choose becomes the library, so every album, name and correction made after it was taken goes with the batch you were trying to remove. There is no way to lift out one batch and keep the rest.
Nothing here touches your files. Setting a date in Needs dates changes PDR’s record of the photo. It does not rename the file and it does not write the date inside it — so undoing has nothing to unwrite. See a record of what was changed, and when.

Opening the same portable library from two computers

No. You are told, and you are not stopped. A library kept on a portable drive records which machine currently holds write access to it, and a second computer that opens it is labeled read-only and shown a message saying another device holds write access. That is where it ends. The label is advice, not a lock. The only operation actually refused on the second machine is the manual mirror-to-drive; a Fix run, a date correction and every other write go through exactly as they would on the first machine. So two computers can write to one portable library, which is the thing this question asks to be prevented. When the computer in front of you is the one that should be working, you confirm your license key and the recorded claim moves to it — but you never needed to.

To do it

Connect the drive to the second computer and open the library as you normally would.
Read the message, and take it as a warning rather than a guarantee. Browsing, searching and viewing all work — and so, for now, does everything else.
To make it official, confirm your license key when PDR asks. The recorded claim transfers to the computer in front of you.
Until the lock is enforced, do the safe thing yourself: close the library on the first machine before you write to it on the second.

Limitations

Nothing enforces it. This is the limitation that matters and we previously wrote the opposite. One check exists in 3.0.4 that refuses an action to a read-only device, and it guards the manual mirror only. No other write consults the claim, so the protection this section is about does not exist yet.
It is a recorded claim, not a lease. There is no timeout and no heartbeat, so nothing expires the claim on its own. If the machine that holds it crashed, was sold or has died, the claim simply stays where it is until another machine takes it over.
Taking over needs a valid license key. That is what stops a stranger who finds your drive from claiming your library — but it also means someone whose trial has ended cannot take their own library back from a dead PC without buying one first.
Nothing on screen tells you the marker is there. It lives in a hidden folder at the top of the library, so most people meet it for the first time as a refusal rather than as a setting they knew about.
The read-only machine does not mirror anything back. Changes cannot be made there, so there is nothing waiting to be merged when access moves — see repeating backups to a second drive.

Known gaps in 3.0.4

These are the specific shortcomings behind the answers above, written down so that a reader comparing products is not relying on our marketing. They are open items, not fixed ones.

No integrity check. PDR never verifies its own index and cannot warn you that it is damaged.
The startup tidy-up removes rather than reports. Index entries for files it cannot see are deleted outright, with no prompt and no summary shown to you.
An unplugged drive is indistinguishable from a deletion. The check that drives the tidy-up asks only whether a path exists, so a detached drive is treated as permanently gone.
Restoring an earlier copy of the index is a replace, not a merge. The copy you choose becomes the index, so anything you did after it was taken is lost. There is no way to recover one folder, one person or one album from a copy while keeping the rest.
Modified files are not detected. Nothing compares timestamps or contents, so edits made in other programs leave the index silently out of date.
The audit log is never written. The routine that would record every date correction sits in the application unconnected, so the log file is never created and there is nothing to view.
Setting a date by hand does not write it into the photo. A date you set in Needs dates updates PDR’s record only — the file is not renamed and its own metadata is untouched, so nothing outside PDR sees the correction until you Fix those files into a destination.
The read-only marker on a second computer is not enforced. Only the manual mirror is refused; every other write proceeds, so two machines can write to one portable library.
A rebuild loses face matches, AI tags and album membership. They are attached to index entries and are cleared with them, and the rebuild finds files rather than restoring what was known about them.
The dates shown against backup copies are the library’s modification time, not the time of the copy. Copies made days apart can appear under one date, so the list cannot be used to judge how far back you are going.
Nothing takes a copy before a Fix run, a rebuild or an organizing pass. Automatic copies are taken at launch and before four face-recognition actions only.
No settings export or import of any kind.
A Fix run always produces a second copy. There is no sidecar or database-only mode, so you cannot ask PDR to record a correction without writing a new file. Correcting a large library costs the disk space of a second copy of it.
Editing a caption can overwrite the photo’s original date with the file’s modification time in some paths. This is a defect, it is being tracked, and it is the reason we suggest keeping a copy of anything irreplaceable before a bulk edit.

How to check any of this yourself

Nothing on this page asks you to take our word for it.

That corrections never touch the original: note a photo’s file size and modification time, run a Fix on it, and look at the source again. Both are unchanged, the filename is unchanged, and the corrected version is a separate file in the library folder you chose.
That indexing does not write: add a folder of photos, let it index, and compare modification times before and after. They will not have moved.
That an unplugged drive empties from the index: index a folder on a removable drive, close PDR, detach the drive, and start PDR again. Those photos will be gone from search. Reattach, rebuild the index, and the photos return — but check an album and a named person afterwards, and you will find the photos are no longer in them.
That the second computer is not actually stopped: open a portable library on a second machine, read the read-only message, and then run a Fix anyway. It will run.
That the backup dates are unreliable: open PDR three times in one morning, then look at Settings › Backup. Copies from three different launches will be listed under the same date and the same size.
That the audit log is real: apply a date correction, then open PDR’s application-data folder and look for the corrections log. Your change is the last line, with its timestamp.
That there is no settings export: look through Settings. There is no export, and no file to find.

Every answer on this page was checked against the shipping 3.0.4 build, not against the source code. Confirming that a mechanism exists is not the same as confirming what it does, so each claim here was run on an installed copy with real photos and the result recorded. Where the result was worse than we expected, the answer on this page and the matching answer on our comparison table both say so.

If you find any statement on this page to be wrong on the shipping 3.0.4 build, tell us and we will correct the page. That offer is the whole basis on which we ask you to trust the comparison.