Question [PPPM-6333] Does Obsidian restore websites with correct dates

[mr-wolf]

Not often do I need to restore a website or mail, but what is driving me mad for years is that Plesk does not maintain the original dates of the files.
Does Obsidian do this as well?

I recently restored a site to a previous date and I needed to get the original files with tar to correct the dates.
In case of Mail it even mixes up the sort order for Apple Mail.

 

[EvgeniyKovrizhnikov]

Hi.
Restore really change files dates, and, as far as i know, we don't have any bug related to that problem, because it's not looks like a problem. Could you, please, provide a reasons - why it problem for you in what cases?

About mail - I checked apple mail, mails dates was not changed after restore, so looks like it's not a problem anymore.

 

[mr-wolf]

This is the first time I get a reaction on this, for which I want to thank you.

You may not deem those dates important, I do.
It never was the case and it started somewhere in Plesk 12 or something.
We all do back-ups and just rely on it that we can restore sites like they were.

The normal situation is that you don't need it. Many don't know it's a problem as they never have to restore a site.
Maybe some don't complain because they are already happy they have their files back.

> Could you, please, provide a reasons - why it problem for you in what cases?
It is a problem because the file dates are wrong. They need to have the date they were last modified.

They still have the correct date in their tar-files, so why are you not preserving them.
It may well be a forgotten "-p" somewhere.
No-one ever bothered to look.

Question - How backup restore works?
Important - Plesk Migrator extension
https://talk.plesk.com/threads/i-was-hoping-this-bug-would-be-fixed-by-now-after-years.352019/

 

[EvgeniyKovrizhnikov]

Hi, thank you for you feedback.

I talked to our backup developer -yes, we have bug for that, but without any ETA, because we have not so many requests about it. Looks like for most of customers this behavior is OK.
But i need to ask again - does this behavior break something to you? Any use cases, please? Or it's only annoying you, because work not like you expect it should work?

 

[mr-wolf]

I don't understand why this needs a vote at all.
Like I already said, most people don't ever need to use back-ups.
They expect a restore to restore what they had without any changes. So NO changes to the filedates either.
Most people are not aware of this bug, but will be when it's too late.

And it is not that you were not given enough time for it.
It is of great annoyance, yet I'm only made aware of it when I actually need to restore data from the back-up.
Then I need to extract the tar-files manually and copy all the files with "cp -p" only because someone at Plesk forgot to use the "-p" in their script (this is speculation, I have not investigated the restore scripts, nor do I want to)

These file dates are of importance when debugging. If something is wrong with the site and you can see for instance that none of the files have changed for a long time or one does. On other occasions it tells me something about the age of the site.
The fact that hackers of sites sometimes take the trouble to match the files they create to those of other files in that site shows how important these filedates can become.

If you take any pride into your product you should just fix what is obviously wrong instead of asking for votes.

BTW.... Roundcube also acts strange after restore

 

[Ales]

I have to agree with mr-wolf here. The restoration process is losing metadata that is otherwise present in the backup, the need to fix this ASAP should be obvious.

Every system administrator will tell you that file metadata is important. The only reason you're not getting more complaints is that people are not aware of the issue.

 

[dash]

Hi,
We have registered Software Issue to handle this, you can track the status using ID: PPPM-6333.
Thanks for your report,

 

[mr-wolf]

This is a corruption of the data we take great care of preserving each day or week. You speak of "votes" to fix something you should be embarrassed of. More effort has gone into talking about how unimportant this bug is for us..... It is NOT!!

If a fraction of that time would have gone into just fixing the mistake you made it would have been fixed a month after I made you aware of it.

 

[Groo]

It is JUNE 2021 - how is this STILL not fixed?!

I spoke too soon - /usr/lib64/plesk-9.0/sw-tar - which extracts the files - actually DOES preserve the timestamps! However, it appears the ENTIRE site is extracted first with the current time ...and so far I see some of the timestamps being processed back to what they were originally.

UPDATE: Restore is finished and bizarrely only a small amount of files have the old time stamp! I have no idea why those were done correctly and others weren't. Guess this is still a problem

 

[mr-wolf]

luckily I don't need to restore a website that often, so I need to re-check this.
I knew that all this time the dates of the files inside the back-up still had their correct dates.

It goes/went wrong upon restoring using plesk.

My procedure to fix this has been

- get the remote tar file on the local server
- restore the site using plesk
- extract the tar
- copy the files of the tar with "cp - pr" to the site's location and correct the dates.

Seeing is believing. Will check it today.

There are 2 big grievances I have with plesk. This is one of them.
I still think plesk is the best.

 

[Groo]

- extract the tar
- copy the files of the tar with "cp - pr" to the site's location and correct the dates.

Check my update above - it's only partially fixed

There is a MUCH faster way to do vs your last step with the copy - use this python script:

Save this as /root/timesync.py

#!/usr/bin/python

import os
import sys

for directory,subdirs,files in os.walk('.'):
    pathes=subdirs+files
    for path in pathes:
        fullpath=os.path.join(directory,path)
        target_path=os.path.join(sys.argv[1],fullpath)
        mtime=os.lstat(fullpath).st_mtime
        print 'touching',target_path,':',
        try:
            os.utime(target_path,(mtime,mtime))
            print 'OK'
        except:
            pass
            print 'FAILED'

Let's say you extract your backup to /restore - cd to that directory and run script as so:

cd /restore
python /root/timesync.py /var/www/vhosts/pleskrestoredsite/

It will update the dates/times lightning fast this way... skip that copy!

 

[mr-wolf]

I just want Plesk to do its work properly.
Just tested it and it's still as broken as it was a few years ago.
unbelievable!!!




FIX THIS!

 

[mr-wolf]

Another year passed.....

Just restored a site from back-up and again all the dates of the files are off.
Inside the tar all the files have a correct date.
This means that somewhere in the restore process of Plesk someone forgot the flag to preserve the dates.

What an uckup.
Not because they made that mistake, but just because Plesk doesn't bother to correct it.
Somehow they decide for us if it's important or not.

Metadata IS important. The whole world thinks timestamps are important.
If someone is taken hostage they use a newspaper to prove when the picture's taken.
It MATTERS.

 

[mr-wolf]

Hi.
Restore really change files dates, and, as far as i know, we don't have any bug related to that problem, because it's not looks like a problem. Could you, please, provide a reasons - why it problem for you in what cases?

About mail - I checked apple mail, mails dates was not changed after restore, so looks like it's not a problem anymore.

You are deciding what is and is not a problem?

yes, we have bug for that, but without any ETA, because we have not so many requests about it. Looks like for most of customers this behavior is OK.

No, it doesnt mean most customers think this behavior is OK.
That's the wrong conclusion.
People do not have to restore that often. I only need that feature once a year.
Most people would not notice it then as the site is working again and they have to do other stuff.

Those timestamps are important if you're troubleshooting that site if something is not working.

 

[vic666]

Just before, I was running some tests on an internal wiki and before doing so, I created a backup. Since the tests were not succesful, I decided to simply restore my backup and assumed everything would be back exactly to how it was.

Instead, for every single file that was restored, the creation date was changed. This is terrible because my wiki is file based and the file metadata defines the page properties.

At first I thought that I must have done something wrong, then I started googling. I'm quite horrified to come across this thread that seems to confirm that this issue has been around for over 5 years.

Please make it either the default that metadata is preserved in the backup and restore, or at least make it an option.

 

[vic666]

Since I can't edit my post, let me just make a correction: I meant the modification date, of course, not the creation date (which is not stored in Linux anyway).

 

[mow]

not the creation date (which is not stored in Linux anyway).

It is stored (birth date), but it can't be modified from user space (intentionally immutable), so there's no way to restore it with tar.