restore fails

[ScsParticipant]

I am trying to restore a WordPress site to another webserver. When I select Restore I get the error below and the restore fails. What permissions do I need on the WordPress directory?

UpdraftPlus Restoration: Progress

Final checks
Looking for db archive: file name: backup_2013-12-10-1611_Superior_Spotlight_77dfebcd43a5-db.gz
Archive is expected to be size: 832.9 Kb: OK
Looking for others archive: file name: backup_2013-12-10-1611_Superior_Spotlight_77dfebcd43a5-others.zip
Archive is expected to be size: 1937.5 Kb: OK

Enabling Maintenance mode…
Testing file permissions…

Disabling Maintenance mode…
Looking for plugins archive: file name: backup_2013-12-10-1611_Superior_Spotlight_77dfebcd43a5-plugins.zip
Archive is expected to be size: 9752.7 Kb: OK

Enabling Maintenance mode…
Testing file permissions…

Disabling Maintenance mode…
Error: Could not move old directory out of the way. You should check the file permissions in your WordPress installation

Restore failed…
Actions: Return to UpdraftPlus Configuration

[udadminKeymaster]

Hi Lisa,

It’s the wp-content directory’s permissions that are relevant for that check – it needs to be writeable by the webserver.

However, if you can wait until tomorrow and update to the new UpdraftPlus version (which should be available tomorrow), then it requires less permissions, so should succeed on your existing setup.

David

[ScsParticipant]

OK

[ScsParticipant]

I tried to do another restore today after updating to the latest version of updraft (Version 1.8.1.13) and it said it was successful. The problem I am running into now is that the formatting is way off and the links on the webpage do not work. The wp-admin portion of the site is functioning correctly but the webpage itself is not.

[udadminKeymaster]

Hi Lisa,

Can you send me a link to the restored site so that I can take a look?

Failing that, can you send me a copy of the backup set (e.g. share it via Dropbox or Google Drive with me), so that I can reproduce the operation and see the results.

However, before you do that, try this…. It’s possible that the site you’re cloning has hard-coded relative links. It’s best to migrate the site to the same relative location as the original. What I mean by that is, if the original site is at https://example.com/subfolder, then when you clone it, migrate it to https://localhost/subfolder. If the original site is https://example.com/, then migrate it to https://mysite.localhost/. That way, even if your site has hard-coded links to relative paths, then they’ll still be fine after the cloning. (It’s not possible to second-guess what the site developer was doing if he hard-codes short-hand stuff… the search+replace can only work on full URLs, replacing the full site URL from the source with the full URL of the destination).

Best wishes,
David

[ScsParticipant]

The migrated site is not live yet (not open to the internet). I can give you access to the files on dropbox? What is your email address and I’ll send you an invitation?

The plan is to clone the site to a new server but keep the same URL. Both the server we are migrating from and the intended new web servers are WIMPs.

[udadminKeymaster]

Hi Lisa,

Dropbox is fine… use the address contact at updraftplus dot com.

Many thanks,
David

[ScsParticipant]

You have now been invited to the shared folder. The invitation should be in your email.

Thanks

[udadminKeymaster]

Hi Lisa,

Thanks – I will take a look.

David

[udadminKeymaster]

Hi Lisa,

The issue is as follows… the site has various hard-coded links to resources not stored directly inside WordPress. e.g. Like this one, to the stylesheet (which is what controls the layout):

<link rel=”stylesheet” type=”text/css” href=”/styles/common.css” />

However, if you’re cloning the site to a sub-directory, e.g. to https://localhost/wordpress, then the relevant resource will actually be in https://localhost/wordpress/styles/common.css – whereas the hard-coded link causes it to be looked for in https://localhost/styles/common.css, so it’s not found.

It’s usually a bit annoying to un-do all the hard-coding in the original site, so the simplest way to work around this is to set up your cloned site so that it’s at a sub-domain rather than a sub-directory. i.e. at something like https://mysite.localtest.me (this needs your webserver to be tweaked to recognise the host name mysite.localtest.me). Then, the hard-coding will still work.

I hope that makes sense – let me know if not!

Best wishes,
David

[ScsParticipant]

I am cloning the wordpress site to https://localhost and not to a sub-directory. I added the styles/common.css and it looks better but the links are still broken. Another thing that is off is that I need to type in https://localhost/index.php instead of https://localhost to get to the website. I would like to be able to navigate to https://localhost and get to the website.

[udadminKeymaster]

Hi Lisa,

Are you sure about that? Our updates server is showing that the WordPress site checking for updates connected to your account is: https://localhost/wordpress

Have you got WordPress in a sub-directory? If so, then it may be that your manual directories just need moving post-migration. i.e. Look in wordpress for them, and move them up a level.

Best wishes,
David

[udadminKeymaster]

Just to clarify – when I say “WordPress in a sub-directory”, I’m referring to a non-default WordPress setup where the WordPress files are not in the same directory as the website home is based at.

For the index.php issue, that’s a webserver configuration issue – you need to find out how to configure your webserver to regard index.php as a “default” page that is searched for when no specific file is indicated. With Apache, this is the DirectoryIndex directive – https://httpd.apache.org/docs/2.2/mod/mod_dir.html – in your Apache configuration file.

David

[ScsParticipant]

I was able to change the default document for the website, so I can browse to it now with https://localhost, however all of the links are still not working. This is the error I get in IIS:

HTTP Error 404.0 – Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.Most likely causes:
The directory or file specified does not exist on the Web server.
The URL contains a typographical error.
A custom filter or module, such as URLScan, restricts access to the file.
Things you can try:
Create the content on the Web server.
Review the browser URL.
Create a tracing rule to track failed requests for this HTTP status code and see which module is calling SetStatus. For more information about creating a tracing rule for failed requests, click here.
Detailed Error Information:
Module IIS Web Core
Notification MapRequestHandler
Handler StaticFile
Error Code 0x80070002
Requested URL https://www.teamscs.com:80/our-work/our-clients/
Physical Path C:\inetpub\wwwroot\scsweb\our-work\our-clients\
Logon Method Anonymous
Logon User Anonymous

[udadminKeymaster]

Hi Lisa,

I could do with the information about the directory structure of your WordPress install that I mentioned in the previous couple of posts, so that I can work out how you’ve got WordPress set up: a) What is the full path to the directory where WordPress is installed? (i.e. the directory that has sub-directories wp-includes and wp-admin, amongst others). b) Is that the same directory as the index.php file that is serving https://localhost, or is WordPress in a subdirectory underneath where index.php is?

Best wishes,
David

[Author]

Posts