Yhyjyk

We want to take a backup of everything on our server, which is running remotely on the other side of the world, without shutting it down.

(It's a debian system.)

A lot of the backup advice I see, like using dd, seems to presuppose that the drive is unmounted and not in use. But am I not supposed to exclude "living" directories like /proc and some of the subdirectories under /var (however, some of the stuff under /var I know we definitely do need to keep) and /mount? What else is there that I need to think about in this situation? Then I guess I can just snarf it with rsync and using a bunch of --exclude flags.

Or are there better ideas, especially FOSS friendly ones?

Edit:
I want to clarify the question with some deets&context.

The system runs on Linode.

This system is running shell, email, XMPP/prosody and web, with a couple of simple nginx setups.

We want to backup files related to those things just to be safe. For example, files users have stored in their home directories.

We don't need to exactly copy the existing setup wrt every single /etc file; instead, the reason we're even doing the back up in the first place is so we can move it all to a new setup (newer version of Debian still on Linode).

The reason this question exists is that when I've tried making backups in the past I've kept making either of these two mistakes.

• I've went "OK, I'll just copy / and everything under it" and then got stuck in some weird infinite loop either because of the drive I was copying to was mounted under /media/backup and it was copying itself recursively [obv that specific problem not applicable here since we're gonna backup over rsync or similar] or it has gotten stuck trying to copy some "alive" stuff in /proc or /var or whatever, like trying to keep up with ever-changing logs, or
  


• I've went "OK, I'll just grab the bare minimum of what we need… hmm, everyone's home directories, and our web server directories (all under /var) and let's snag a copy of /etc and all the old mails under /var/vmail" and then I’ve invariably fucked up file permissions or timestamps (gonna make sure I don't backup unix files to a FAT drive this time) or forgot something ("oh, shoot, I had some custom scripts in /usr/local/bin that I never stored anywhere else, I forgot to get those, guess they're gone now").

So obv copying the entire drive straight up has lead to pitfalls and copying directories selectively has lead to pitfalls. I want to know how to do it right.

Two helpful souls♥ have already posted links to other questions on here; one wasn't really applicable since A. they had a Windows server, while we have Unix; B. they had fragile physical hardware, while we have Linode under KVM, C. they had an awkward social situation with a boss, while we’re a bunch of artists trying to go DIY. The other was applicable as a general text of philosophy and good practices and I am going to try to strive to implement those things (automated backups etc) but I was looking for these more specific details of:

• Which directories do I need to copy and which do I exclude (given that it’s a system that’s currently running & and serving up a wiki, XMPP chat, email — with new messages coming in while the copy job is running)


• What file attributes such as time stamps & owner & group do I need to present and how do I do that? ← I think I can answer this half of the question myself with something like… um… rsync -HXaz I think is a good option for us? The -z obv not really related to the question which is "what do I preserve"

While writing this edit I mentioned that we are on our hosting company's KVM. While logging in to check that, I saw that they have a backup service. I didn't know that as I was writing the original question. Obv I'm gonna try to learn how to use that service, and that'll be a great solution for us in the short term solving the kinda crisis we're in rn. But in the long term we also need backups of our own, here, in case they go under or something else weird happens. [If anyone from that company reads this, don't worry, we're not looking to go shop around rn. We're happy with your service. We just want to keep our data extra safe.]

Again, big thanks to everyone who's already answered and who has posted links to those other two questions.♥

In Linux everything is a file. It's possible via rsync, but there are things to be aware of, that are (at best) difficult to get around.

You should think about replication first, especially for databases. Also this is a good idea to set up proxy / load balancer in front of your primary server, so you can easly switch back and forth with your primary and mirror servers during transition.

At the hardware level the best situation will be to have mirror-like server on another side, with the same number of ethernet ports, same hdd layout and so on. Everything that differs implies the need of system configuration changes.

i.e. if you have two eth ports, you want to make sure that network configuration, firewall and so on matches the interface name on both servers, and in case it differs you either need to change configuration after rsync or change the device name on the second (destination) server.

Same with partition layout. You should create same partitions as on your primary server, but if you create them from scratch you'll end up with diffrent UUIDs, so you will need to change fstab, grub, mdadm (if soft-raid is involved), and so on.

But, there are also many things that may go wrong, like databases, which can be inconsistent if not previously stopped (before doing rsync).

The best strategy will be to first prepare hardware and filesystem (partitions) - to match primary server's configuration. Then mount empty parititons via intermediary system (like live CD with ssh-server installed temporarily). You create empty /proc, /dev, /sys and then rsync the rest, like so:

rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/

Then you need to install grub on the device and work on configuration, to make it bootable, change network configuration, fstab and other stuff mentioned earlier.

You may also try to install fresh system (with same version that you're using on your primary server), then power it off, mount it via another, temporary system (like live cd), then replace anything other than /proc, /sys, /dev and /boot with rsync.

But it's only general idea. Things might complicate depending on what you actually have on this server, what is your configuration, network and hardware setup. And in the end of the day this might be really hard or impossible to do it without noticable downtime.

I my opinion It depends what and where you running server with internal linux command it is not possible, you have to mimic/pipe complete data and libraries . If you running on vmware and configured well it provides live migration. Or else you have to use third party tools. Hope this will help you. Some more references How do I make a backup of a live server?

Rsync is good command to sync the data between servers.

There are 2 solutions available, where you do not need to rely (anymore) on missing bits as well as missing one item off your list because of an incomplete checklist or maybe because just something hot overlooked.

Firstly, if you move this onto a platform with some more control over the underlying hardware platform, you can take disk snapshots of all files while the server is running. For example on AWS you can snapshot an EBS disk and even only pay for the differences when you make another snapshot later.

Secondly, I recommend to script the setup of your complete server with a configuration management system, such as Ansible. This will

• document everything you have configured in source control




• allow you to test recreate the server from backup or bare metal to make sure your scripts are up to date




• allow you to rerun the script on a newer operating system, usually with quite minor changes.