It wouldn't surprise me if things were sometimes different. Plesk never used to mess with the filedates and at a certain time they did.
I believe they now sorted that problem (
EDIT: no they didn't(. The behaviour I described I noticed on Onyx. Never did much restoring in the past.
Maybe I have some opportunity to confirm my thoughts on that tomorrow...
EDIT:
I wrote a special script for it, but that wasn't necessary as it didn't behave like I think it did.
Files that were added since the backup were
not deleted and there was
no rebuilding....
I tested it on 17.8.6
I thought I saw this rebuilding in the past and have taken that knowledge into account ever since...
A mistake so it now seems.
So.... One should remove folders before doing a restore if you really want to get rid of some stuff.
@Peter Debik answer is the correct one.
EDIT:
And it gets worse....
The restore bug is not fixed yet....
All the dates of the files have been changed to today's.... Grrrrrrrrrrrr....
Luckily I still have these files somewhere else with their original timestamp.
I did test on a folder of an obsolete website, but still....
PS
I may have seen this behaviour during a migration....
Would need to test for that, but I can remember losing a website because I used the migration tool to migrate the mail to another server where only the website of that same domain was running.
I wanted the mail and website for a specific domain back together again as LetsEncrypt needs a website to generate certificates for webmail. A mail-only site is not supported.That client was using webmail a lot and I wanted it to be secure. Mail and Website needed to be together on 1 server for that
I expected it to merge these 2 as I told the migration tool to
only migrate the mail....
It did NOT merge. It destroyed the website on the target and this resulted in a lost website.
I then needed to restore the site by using the back-up tool.
This resulted in
a filestructure with all filedates set to the moment of restoration.
That was indeed a day I was cursing on Plesk (and myself for assuming too much).