restore fails

UpdraftPlus Home › Forums › Paid support forum – UpdraftPlus backup plugin › restore fails

Viewing 15 posts - 1 through 15 (of 21 total)
1 2
  • Author
    Posts
  • December 10, 2013 at 6:08 pm #17986
    Scs
    Participant

    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

    December 10, 2013 at 8:40 pm #18393
    udadmin
    Keymaster

    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

    December 10, 2013 at 9:20 pm #18394
    Scs
    Participant

    OK

    December 11, 2013 at 7:57 pm #18396
    Scs
    Participant

    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.

    December 11, 2013 at 8:49 pm #18400
    udadmin
    Keymaster

    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

    December 11, 2013 at 9:25 pm #18401
    Scs
    Participant

    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.

    December 12, 2013 at 12:42 am #18405
    udadmin
    Keymaster

    Hi Lisa,

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

    Many thanks,
    David

    December 12, 2013 at 2:32 pm #18407
    Scs
    Participant

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

    Thanks

    December 12, 2013 at 3:51 pm #18408
    udadmin
    Keymaster

    Hi Lisa,

    Thanks – I will take a look.

    David

    December 13, 2013 at 1:52 am #18412
    udadmin
    Keymaster

    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

    December 13, 2013 at 3:03 pm #18413
    Scs
    Participant

    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.

    December 13, 2013 at 3:29 pm #18414
    udadmin
    Keymaster

    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

    December 13, 2013 at 3:40 pm #18415
    udadmin
    Keymaster

    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

    December 13, 2013 at 8:21 pm #18416
    Scs
    Participant

    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

    December 13, 2013 at 8:42 pm #18417
    udadmin
    Keymaster

    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
Viewing 15 posts - 1 through 15 (of 21 total)
1 2
  • The topic ‘restore fails’ is closed to new replies.