Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I run several e-commerce sites off my home server (my own, a family member's, and a customer's). Its an older Dell Dimension 4600 that I have running Ubuntu 12.04 lts. The computer doesn't show any signs of imminent failure, but with it being old, I want to have a good backup of it in case anything would happen. I would need to be able to restore the data to a new server within a couple of days of the server going down Is the best way to use something like Clonezilla? Or should Is there a better method to do this?

Update

I don't need the site to be live while I do it, and I currently have about 8Gb of data. A bit copy seems like a good idea for what I want, which is to make the backup and then if anything happens, be able to plug the backup disk in and go. The disk layout is only one disk, one big 80GB partition. Yeah, I know this is not the best, I was brand new to the whole world of Linux, Ubuntu, Web Servers, pretty much everything when I installed the OS and initially set it up. So no LVM either

share|improve this question

2 Answers 2

up vote 4 down vote accepted

If the site does not need to be live while you do it, there are a raft of solutions, the easiest being to ensure the disk is mounted read-only (for example by using a boot disk) and do a bit copy from 1 disk to another. Then if something goes wrong, you just shove the backup disk in, turn the server on and away you go.

If the site needs to be live while doing the copy, the problem is more complex. A good way of handling backups under Linux is to schedule incremental backups using something like rsnapshot (but rsync might be easier in your case). If you have to restore though you will need to start by rebuilding the server, then copying the latest snapshot across.

You have not indicated the quantity of data you are backing up, how often it changes or the layout of disks. Both of these things are useful in coming up with a backup solution. If you are building a new system (or had the foresight when you built the original system), it is often useful to build the filesystem on LVM, then take a snapshot of the LVM and back it up. This means no downtime and you can make an exact copy of [most of] the filesystem at a point in time. It does, of-course, assume you use LVM.

Similarly, if you have good seperation between your OS and application, you might want to start with a base install of Ubuntu 12.04, then back up just the applications incrementally. You might also want to handle databases differently to web files by dumping the databases. Similarly tar (sometimes on block devices) can be good for complete, compressed backups - but when backing up block devices be aware that file changes during the backup of the block device can come back to bite quite hard without care.

Unfortunately its difficult to get more specific then this because backups are somewhat system specific.

share|improve this answer

For a situation like this, the best way is probably to have another server where you can sync your data. Buy a VPS and sync your code, databases, and configs. I just checked a provider I use and you can get a VPS with 20GB space, 512MB RAM, 1.5TB transfer, and 2 IPs for $20 a year. Double the specs and it's $40 a year. Peanuts. If you don't like the bargain boys, you could do Amazon Cloud or Slicehost, but I think you're wasting your money.

When you do code changes, use Dreamweaver (or whatever you use) to make changes to your "test" site. Then promote your data to the "production" site. Most web development IDEs have the ability to have a "test" server and a "prod" server. You pick, which is which. If it were me (and I have pretty close to the exact same situation with some clients), I would set the VPS as the production site and use the home server as the backup site.

Initial setup of this is easy. You can dump all of your installed packages from apt-get into a txt file and use that to install the same packages on your VPS. Tarring up the web files, the database dumps, and you can use SCP to copy them right to your other server. (Probably do it all with a short shell script.) You'll probably want to copy over most of your /etc too. Once the initial setup is complete, keeping things in sync is trivial.

This has many advantages.

  1. First, the power goes out in your home and your server doesn't go down.
  2. Second, code changes are tested and developed over your LAN so they are fast and you're not waiting to push data across a slow connection (YMMV).
  3. You have a hardware failure and need a part that takes a week to get - your production site stays up.
  4. You can SSH in to your testing server from anywhere, make changes, test them and then push them to your prod server with minimal disruptions.
  5. You can develop on the exact same configuration as the production machine. So you don't have to use XAMPP or some other development environment and worry about dependencies, structure, or all the other development nuances.
  6. Co-location. If your production machine fails (VPS) for some reason, repoint your DNS to the home server. Keep your DNS TTL at 30 minutes and your down time is minimal.

So, that's my recommendation.

And, yes, I charge people $1000+ a year for a VPS that costs me about $40 a year... I also upsell them co-location services, which is just another VPS from another provider or on my home rack. You gotta stand on the shoulders of giants if you want to make a buck in the web game. Developing code is nice, but residual income is where it's at, brother. Buy low. Sell high.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.