dkusleika's questions

I want to develop an automated process for checking that every machine on our domain is getting backed up. I'm wondering how other people do it.

We have a SAN (virtualized windows and linux servers and three SQL Servers) and a couple of NAS in our data center, a couple dozen physical DCs in the field (Win Server 2016), and a few hundred workstations (soon to be all Win 10). We keep Veam snapshots for a month locally, then push them to AWS after that.

Recently we needed to restore an Excel file that was used to update a table on one of our SQL Servers. We failed. The share on the NAS where the file lived was not being backed up. When we created the backup process, the share was barely used and I'm sure we chose not to back it up on purpose. But as we gradually started using that share for more important stuff, we didn't change the process.

Next we tried to restore the data from the SQL server. This server was added in the last year and, while it was being backed up, we missed the part where we pushed it to AWS so we only had it going back one month.

We should have backed up that share from the beginning - important or not. And we should have been pushing the new SQL backups to AWS. My take away from all this is that there are too many places for human error in our process.

One idea we had was to get every machine from Active Directory and select a "random" file from each drive/share (excluding system files and executables) and see if we can find it in our backups. We could automate the selection process with PowerShell. I'm not sure about automating the checking of our backups, but hopefully there's a way. If we had to manually do it for a few hundred files it would be better than nothing.

Is there a best practice for backup completeness? Is there something better than the humans-being-careful method?

I'm trying to move a Wordpress site to Nginx from Apache. When I go to the main site, it renders as expected. When I click on a post, it tries to download index.php instead of processing/rendering it.

I setup nginx according to https://www.linode.com/docs/websites/lemp/lemp-server-on-ubuntu-16-04

My nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 768;
    # multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";


    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

and my li394-200.members.linode.com file in sites-available

server {
    listen 80;
    listen [::]:80;

    server_name li394-200.members.linode.com;

    root /var/www/html/li394-200.members.linode.com/public_html;
    index index.html index.php;

    location / {
        try_files $uri $uri/ /index.php$args =404;
    }

    location ~ .*\.php$ {
        include snippets/fastcgi-php.conf;
        include fastcgi_params;
        fastcgi_pass unix:/run/php/php7.0-fpm.sock;
        fastcgi_param SCRIPT_FILENAME /var/www/html/li394-200.members.linode.com/public_html$fastcgi_script_name;
    }
}

If I navigate to http://li394-200.members.linode.com/phptest.php it renders as expected. Also http://li394-200.members.linode.com/index.php is correct. But if I go to http://li394-200.members.linode.com/archives/2016/11/02/international-keyboard-shortcut-day-2016/ it says 'You have chosen to open ... application/octet-stream.' When I say OK and download it, it's index.php from my wordpress directory.

My permalink structure is /archives/%year%/%monthnum%/%day%/%postname%/. If I change the permalink to Plain, I can navigate to http://li394-200.members.linode.com/?p=11240 correctly.

I followed the advice at http://nginxlibrary.com/wordpress-permalinks/ and added

try_files $uri $uri/ /index.php?args;

to the location block. When I restart nginx, I get

[emerg] try_files directive is duplicate in /etc/nginx/snippets/fastcgi-php.conf:5

I don't even see where I'm including that file. But that file looks like

# regex to split $uri to $fastcgi_script_name and $fastcgi_path
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Check that the PHP script exists before passing it
try_files $fastcgi_script_name =404;

# Bypass the fact that try_files resets $fastcgi_path_info
# see: http://trac.nginx.org/nginx/ticket/321
set $path_info $fastcgi_path_info;
fastcgi_param PATH_INFO $path_info;

fastcgi_index index.php;
include fastcgi.conf;

so $fastcgi_script_name must contain the same thing, but I don't know how to see what that is. I don't see anything in my public_html directory that looks like a fast-cgi script (although I might not know it when I see it).

Whether I use my custom permalink or the default one, there is no .php in the URI, so I don't get how that location directive is even capturing it.

I can't get to goodtodo.com from any computer in my office. I don't seem to have a problem getting to any other URL. The server is a Windows 2003 Server and is the domain controller, DHCP server, and DNS server. Most clients are Win XP, but some are Win 7.

If I ping goodtodo from the client, I get "..could not find host". If I ping the IP (74.80.216.31) from the client, I get 0% loss. The IP also works in the browser. Flushing the dns on the client doesn't fix it. ipconfig /all on the client shows the 2003 server as the DNS server.

On the server, I can ping goodtodo successfully. It shows two DNS servers, 127.0.0.1 (itself I assume) and 192.168.1.30 (a windows 2000 server that used to be the domain controller, but was replaced and demoted about a month ago). My guess is that the server is using its secondary DNS server to resolve the name and that's why it works from there.

The problem started right about the time we switched servers. I think it's related because of the timing, but I can't be sure.

On the 2003 Server, the DNS has a cached entry for goodtodo with two entries

(same as parent folder)   Name Server(NS)  ns1.wshost.net
(same as parent folder)   Name Server(NS)  ns2.wshost.net

If I Clear Cache on the 2003 server, the problem goes away for about 4-7 days, then comes back. Clearing the cache fixes it immediately every time.

On a client machine, nslookup goodtodo.com 8.8.8.8 resolves correctly using google's name server. So it seems that it's the DNS server on the 2003 box. Since clearing the cache fixes it temporarily, it seems that the cache gets polluted at times, but that's pure speculation as I don't really know what I'm talking about.

There is a Sonicwall firewall between the server and the cable modem. I ruled that out as a problem since the google name server worked OK. Also, I don't see anything in the firewall settings that would affect this URL compared to any other normal HTTP request.

Am I missing something obvious or are there some other things I can do to narrow down where the problem is?

Additional Information

It came back a few hours after I posted the question - inexplicably to me. Today it went down again. I checked the cache and it was the same as I reported above.

Using google's name server still worked as before and I could ping the IP address of the site directly without error. nslookup goodtodo.com ns1.wshost.net times out on both the client and the server. ping ns1.wshost.net times out on the client, but works OK on the server.

I deleted the entry in the cache for goodtodo.com on the DNS server and everything started working again. I still can't ping ns1.wshost.net from the client. I went and looked at the cache after I visited the site and there were three records: the two I list above plus an A record that references the IP address. The TTL on the name server records is 24 hours and on the A record is 14 minutes. The A record is now gone, but the name still resolves.

In any event, it seems that the DNS server is going to its cache, but is unable to resolve ns*.wshost.net. If I delete the records from the cache, I assume it's using the root hints to resolve the name similar to if I cleared the whole cache.