1

We currently have an application running on a dedicated server which utilizes a LEMP (Linux, Nginx, MariaDB, PHP) stack. Right now we are only doing backups at a set interval (every x hours). I have been researching how we should go about having a live backup and was curious what other people were doing?

Currently our idea is to have another server in a different geographic location which has mariadb installed, then sync the databases creating a live read-only copy of our production database on this backup server. For files uploaded by users we would setup rsync to sync to the backup server when changes are made to the uploads directory on the production server. Does this sound like a solid plan?

Also, the thought has crossed our minds that if we are going to be paying for an additional dedicated server, that we should run the application from both servers, configuring DNS to round robin between the two. This would not only provide us with a backup, but also provide us with fault tolerance in the event one of the servers goes down.

Are we on the right track or have we missed some vital element?

nullReference
  • 263
  • 1
  • 3
  • 11
  • 1
    `This would not only provide us with a backup, but also provide us with fault tolerance in the event one of the servers goes down.` No, this only provides you with a level of fault tolerance, but not a backup for many failure modes, e.g. due to an attacker or a software issue that leads to data loss. – Sven Dec 20 '17 at 17:02

2 Answers2

2

You are addressing redundancy. That is good. You could fail over to the back up server in an emergency. This is NOT A BACKUP solution. You want your backups, especially for a web app to go back in time.

If a developer comes through and runs DROP TABLE myApp_users, that change will propagate to your read-only backup server and you will have no way to recover.You need to be able to go back a reasonable amount of time.

If someone finds a way to update your logo or a user uploaded file on the main server, the change will propagate to the backup server via rsync.

You need to dump the database at intervals, and copy the files somewhere at intervals and keep x amount of time worth of data to call it a backup.

Daniel Widrick
  • 3,488
  • 2
  • 13
  • 27
  • This is a very good point. My main concern was if something happened to the server raid that made recovery impossible. I hadn't taken into account database corruption or defacement. – nullReference Dec 20 '17 at 17:36
0

That backup strategy seems good. There are probably ways it could be improved, but it will improve your current situation. You still need backups, to mitigate database corruption, attacks, etc.

Round robin with basic DNS probably isn't the best idea. Some clients will always use the first record, some won't fail over. Using something a bit smarter like AWS Route53 or CloudFlare that can do health checks and cut off traffic to an unresponsive server would work better.

Tim
  • 31,888
  • 7
  • 52
  • 78
  • Funny you mention CloudFlare. We have been considering migrating our dns to them from dyn and leveraging their static content cdn. – nullReference Dec 20 '17 at 17:27
  • I've used the CloudFlare free plan for years, and I've put a few dozen people onto it. I rate CloudFlare very highly. You have to be careful with configuration, which means setting caching headers appropriately on your origin server, and setting up page rules to cache / not cache applicable parts of your site. Also be careful with the https setup to avoid problems - it's not difficult and it's easy to fix anything you mess up if you have some idea what you're doing. – Tim Dec 20 '17 at 17:48
  • Is there any downtime involved when migrating your dns records? I wouldn't think so since your adding your records, then changing your nameservers at your dns registrar. I would think while the nameservers are being propogated some users might get served dns from your old provider and some might be served from cloudflare until propogation completes. Just wanted to ask to make sure. Please correct me if I am mistaken. – nullReference Dec 21 '17 at 17:42
  • If you do it properly there's no downtime. 1) Set up CloudFlare, which copies all your existing DNS records 2) Change your name servers to point at CloudFlare. Easy. – Tim Dec 21 '17 at 18:22