nginx rules to backup_migrate dirs and files

Depends on the way you have the site setup and where you have the backup directory, but something like this:

location ~* ^.*/files/backup/.* {
  deny all;
}

Sorry I don't use backup migrate so I'm not sure of the directory structure.

We have a helpful group at http://groups.drupal.org/nginx (with some sample configs listed up at the top) if you want to follow up or have further questions.

Also a good idea to locate the backup directory outside the web root, which I believe is possible with the 2.x version?

Can somebody with nginx experience help me do a write up of how to protect the files that I can add to the README.txt?

Thanks

@Ronan

I ask to a specialist on nginx and the answer was:

https://github.com/perusio/drupal-with-nginx/issues/66#issuecomment-9360512

The code setup it.

location ^~ /backup_migrate/ {
    internal;
}

He suggest to install ngnix_accel_redirect

If you update the description of the module with this info could be great!

@kilua99

Awesome. Thanks for running this down! I've put it in the readme file.

r

The documentation for nginx setup isn't quite accurate. I added the configuration mentioned in the documentation (and in this discussion), but was unable to perform backups. The backup directory was still publicly accessible. (Actually, in my case, another bit of configuration made it locally accessible, but publicly inaccessible, but that was enough for the plugin to halt the backup.)

The rule outlined in the documentation is as follows:

location ^~ /backup_migrate/ {
    internal;
}

In nginx, the ^~ portion means "the path of the request starts with this literal string." For most Drupal sites, that means the configuration snippet should be:

location ^~ /sites/default/files/backup_migrate/ {
    deny all;
}

With regard to the difference between internal and deny all, the latter should be obvious; see this documentation for the former.

But you have to allow somebody to access that folder, for example. nginx ? ... Idk it's working well for you?

@George Rahman:

Your logic is sound. I don't speak nginx so I'll take your word for it. If no other nginx users object to this new advice, I'll update the README.

@kullua99:

If nginx is anything like other web servers in this regard, then these instructions are merely telling nginx not to serve the files to the public. It is not preventing it from reading them (or preventing PHP from reading or writing, which is what is needed). Setting the mode of the file to 0000 would do what you've described and would not allow you to restore from or download your own backups via the web. Set that on the folder and you won't be able to back up to it. So don't do that.

Ronan

@ronan

Right, but not even close.

I mean, you can see the perusio reply in github, he's an expert of nginx we can ask about the deny all; rule or internal; one.

If you're in the server and want to access the folder you need internal; rule, if you don't want to any even the user in the server then deny all;

So if you setup an deny all; rule in apache even the server don't have access to the path.

If you see the documentation you'll see the code like

 allow  192.168.1.0/32;
  deny   all;

But well .... maybe I don't explain well, if this guy want to handle the backup and migrate folder just need to.

location ^~ /sites/default/files/backup_migrate/ {
    internal;
}

That's all, if the README say "location ^~ /backup_migrate/" well then change it to the right default folder.

and the ^~ mean start with this regexp ... ~ means regular expression. http://wiki.nginx.org/HttpCoreModule#location read the Docu first.

> So if you setup an deny all; rule in apache even the server don't have access to the path.

I think we're differing on the definition of 'access'. If you tell Apache to 'deny all' on a server, you're telling it not to serve the file via http. It doesn't affect Apache's ability to read the file, though that's pretty much moot since Apache won't try to read the file if it's not going to serve it. PHP needs the ability to read and write to the file and in most system that means Apache needs those rights (php runs as the same user as Apache user unless you use GCI-mode). Whatever you set in php.ini or .htaccess has no affect on PHP/Apache's ability to read or write to the files. Those permissions are set at the operating system level (file mode).

All this is applies to Apache though. For all I know setting 'deny all' on a file in nginx may mean that it denies php read/write access to it somehow. It'd be odd behavior, but what do I know.

This is all pretty much moot in D7 of course, because your server backups are saved to the 'private' folder and if you have that protected correctly your backups will also be protected.

#4 don't run for me (as commented in following comments), and #2 do (customizing with my path)

Thanks #7 for the tip (about ^~), I have to change the path according to my private files configuration.

Closing due to lack of response in 4 years.