Snapshot pro managed cloud backups with a unique remote path

Hi all,

I have a question about using the new awesome managed backup options on some of our ubuntu/ngnix based websites we host on AWS. We currently have the path set on some certain sites as follow:
var / www / ip-address (where the wp-config.php is) / htdocs (which has everything else).

When I download the backup, everything looks good except - it only grabs everything in the htdocs directory (but the folder gets renamed to www instead of htdocs?) and bypassing the wp-config.php which is up a parent level in the IP address directory and I can see why.

Now, would this be a problem trying to restore from the hub because of this type of setup? If so, could anyone suggest how to get the wp-config.php formally back into the www dir, also would I need to get htdocs renamed to www since that is what the backup is renaming as the main directory upon completing?

Thanks so much! :relaxed:

  • Vaughan
    • Support/SLS MockingJay

    Hi Eckerd,

    Hope you're well?

    It should be fine with the www. my site uses public_html and restores ok.

    The restore script doesn't copy the www folder itself, it copies from inside that folder using the sites root folder.

    Regarding the wp-config.php, i'm not sure on this, but wp-config.php being outside of the document root is not standard and the script wouldn't be able to work with that setup. ideally you should move wp-config.php back into the webroot, or htdocs.

    Hope this helps

  • Eckerd
    • Design Lord, Child of Thor

    Great about the www not being a problem. I guess the ideal setup (which goes back and fourth) people move their wp-config.php up a level to harden it as mentioned here:

    https://codex.wordpress.org/Hardening_WordPress#Securing_wp-config.php

    Not all of ours servers are setup this way, but many are and don't mind moving it down a level, I need to try it out on one of the dev environments because I have a feeling many things will break ...

  • Vaughan
    • Support/SLS MockingJay

    Hi,

    Yeah, i'm in the same campas those that say moving it outside the webroot has little impact on security.

    Whilst the concept is good & from the outset people may seem to think it hardens wordpress, the contants alldefined in wp-config.php are made available to wordpress itself.

    This means that the information in wp-config.php is still accessible, so any plugin or script that can allow you to add code, or even the theme/plugin editor can simply be used by adding an echo DB_HOST; for example. to display the DB_HOST value.

    So really, anyone who has access to your site admin who can install plugins etc, would easily be able to get those details. So in that sense, moving it outside the webroot has minimal benefits to security in my opinion.

    Hope this helps

  • Eckerd
    • Design Lord, Child of Thor

    Thanks for clearing that up!

    When I first created the instance image of the server as a new AMI on AWS - that was the initial setup, so just a handful of our servers used that AMI which have the same setup (luckily just the small ones).

    Now I just need to see what files reference the location of the wp-config.php again from awhile ago to make it work properly in the original root. Looks like have some digging around to do! - Unless someone knows which files need to be reconfigured? :wink:

    Thanks so much! :slight_smile:

  • Vaughan
    • Support/SLS MockingJay

    Hi Eckerd,

    The instances i've seen where wp-config.php was moved, simply just involved creating a new wp-config.php in root, and then adding an include_once or require() inside that file with the path of the new wp-config.php file location..

    The only other file I know that references wp-config.php location is wp-load.php in the root folder.

    Hope this helps

  • Eckerd
    • Design Lord, Child of Thor

    Would a multisite (such as our main) that has around 60+ sub-sites and a database of around 400MB be too much to use this while in beta? I think so once I fix some of the smaller sites with a parent level wp-config.php would be perfect but I think our main site http://www.eckerd.edu would be too much? Right now I have AWS snapshots + WP Migration Pro doing cron jobs of the DB - but would love to also use this also or as in a replacement.

    Thanks:slight_smile:

  • Vaughan
    • Support/SLS MockingJay

    Hi,

    It should be ok with that size. there's a 10gb limit tho, which includes the DB dump & files.

    But on my site, it's working fine, the overall backup size of just 1 of my sites is 5GB in size, and it's been working fine with that.

    So it should be able to handle that ok :slight_smile: But don't be complacent. you should periodically checkall backups to see if they will actually restoreby restoring to a dev site. but that should be standard practice to test the backups aswell (you never know until it's too late)

    Hope this helps

  • Eckerd
    • Design Lord, Child of Thor

    I tried to run a normal snapshot on one of the ones not working with managed backups to see if indeed it was a whitelist issue, and these used to work but i'm still getting the 502 nginx error so I will be trying to fix the issue by trying https://www.scalescale.com/tips/nginx/502-bad-gateway-error-using-nginx/ these tips. I'll also see if one of managed hostings that also give an error are either apache or nginx, but I'm starting to think all the ones not working are due to nginx (for some reason now....)

    I'll update as soon as I figure it out (if its whitelist + nginx + RDS security policy too strict) Also, most of them are MariaDB's, which I'm not sure play a factor compared to our mySQL instances.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.