Backup of Linux OS Disk

SirMaster

2[H]4U
Joined
Nov 8, 2010
Messages
2,122
This is loosely related to Data Storage, but I don't think ill get a better answer in any other sub-forums.

I'm looking for a good way to regularly back up my Linux server's OS disk. The primary intention is to have a backup of it in case the disk dies so that I can get a replacement drive, copy over the data from the backup, re-install GRUB and then continue normal server operation. I am not really interested in running RAID1 for my OS disk at this time even though that's probably the best solution. I think i get other benefits of having a real backup of the OS disk.

My requirement is that I need to be able to take an image of the root partition on a live filesystem mounted as read-write.

I also think making an image weekly will serve me well. So I'd like to probably end up writing a script that runs Sunday night and takes an image of my drive.

Does anyone do anything like this now? What have you found that works well?

I'm about to preemptively replace my 5 year old Velociraptor with a Samsung 840 Pro this time, but would like to maintain a recent a backup so when the 840 dies I can replant the backup to a new drive and not lose all my OS customizations and updates and everything. So I can get the server back up and running the way it was a few days ago from the snapshot in a matter of hours.

So I was going to put LVM on the SSD and then transplant over my current root and then going forward using FSArchiver (http://www.fsarchiver.org/Live-backup) which I can run off an LVM snapshot so that I can do the image live. I don't really run many services from my Linux OS. It's mainly just ZFS On Linux and a virtual machine host. No database or anything so I don't think consistency should be a big problem doing it live especially if I can take advantage of an LVM snapshot.


NEW PLAN
I was thinking about this more last night and I think I came up with a good solution.

1. snapshot my root drive with btrfs.
2. run an incremental rsync (or btrfs send) to a btrfs backup drive every night.
3. snapshot the btrfs backup.

Anyone see any problems with this idea?

I should always have consistent backups because i'm snapshotting root before rsync, and I will always have a good backup even if a drive starts to fail because I keep snapshots of each backup every night for a month for example. So I can just restore the root fs from any day and find a day that works in case the last few backups were corrupt due to maybe rsync having trouble reading from a partially failing drive.

Do you guys have any insight or suggestions at what software I should take a look at to accomplish this task?


Thanks
 
Last edited:

Joseph F

Gawd
Joined
Jan 3, 2012
Messages
743
Just dd the whole partition to an image file. Simple, bulletproof solution. You can schedule it to run automatically, as well.
 

SirMaster

2[H]4U
Joined
Nov 8, 2010
Messages
2,122
What are the chances of consistency issues of just dd on a live OS?
 
Last edited:

JoeComp

[H]ard|Gawd
Joined
Jan 23, 2012
Messages
1,036
If you want a guarantee of perfect consistency, you need a snapshot, which basically means you either must run LVM (or use btrfs or ZFS for your system partitions).

And you are already aware of fsarchiver, which is the best program I know of for the job.

Certainly do not try to use dd on a live filesystem.
 

SirMaster

2[H]4U
Joined
Nov 8, 2010
Messages
2,122
Thanks. Good to know I was on the right track.

Hmm I actually like the idea of using a single-drive BTRFS as my OS filesystem perhaps. Then I get COW snapshots for backups and rolling back software updates.

I might even use the copies=2 feature to get self-healing ability. It's a 256GB drive and 128GB would be enough for my OS, it's only using 51GB now.
 
Last edited:

jwcalla

2[H]4U
Joined
Jan 19, 2011
Messages
3,629
Using a filesystem with snapshot ability is the best option of course.

Otherwise you can consider just a regular rsync incremental backup run as a daily or weekly cron job. You don't really need to do an image unless you want to keep the partition table info.

Restoring after disk failure is as simple as partitioning the new disk, doing an rsync copy back to the new disk, installing GRUB and updating the /etc/fstab to point to the new disk's UUID.

Code:
#!/bin/bash

backup_host="madarao"
local_host=`hostname`

release=`lsb_release -cs`

server_prefix=""

if [ "$backup_host" != "$local_host" ]
then
   server_prefix="root@${backup_host}:"
fi

backup_path="${server_prefix}/disk2/backup/${local_host}/${release}"

log_file="/var/log/backups.log"

echo "-------------------------------------------------------------------------" >> $log_file
echo " Local Host : ${local_host}" >> $log_file
echo " Backup Host: ${backup_host}" >> $log_file
echo " Release    : ${release}" >> $log_file
echo " Backup Path: ${backup_path}" >> $log_file
echo " Start Time : `date`" >> $log_file
echo "-------------------------------------------------------------------------" >> $log_file

rsync -aqxhW --delete --stats --exclude=".gvfs" --exclude=".mozilla/firefox/27yw7588.default/Cache" --exclude="Steam/SteamApps" --log-file="${log_file}" --log-file-format="" / "$
{backup_path}"

err=$?

if [ "$err" == "0" ]
then
  notify_header="Backup Complete for ${local_host}:/"
  notify_text=`tail -24 ${log_file} | grep -o "Total transferred file size: [[:print:]]*"`
  notify-send -i /etc/cron.daily/deja-dup.png "${notify_header}" "${notify_text}"
else
  notify_header="Backup Failed for ${local_host}:/"
  notify_text="See man page for error $err"
  notify-send -i /etc/cron.daily/deja-dup.png "${notify_header}" "${notify_text}"
fi

echo >> $log_file
 

SirMaster

2[H]4U
Joined
Nov 8, 2010
Messages
2,122
Yeah, I didn't think of an incremental backup. That would be better than making a new backup every week and then deleting old ones.

I think a nightly incremental backup would be good.

Although the point is to have a good backup at time of disk failure. So I have to ensure that the backup is getting good reads of my data. Any way to do that? rsync already takes care of that?

But if the data reads bad the first time then rsync wont even know what the correct checksum should be so I don't think it will be the best.
 

jwcalla

2[H]4U
Joined
Jan 19, 2011
Messages
3,629
Nope. You need some kind of RAID or a good filesystem like ZFS or btrfs to get the data integrity aspect of it.
 

SirMaster

2[H]4U
Joined
Nov 8, 2010
Messages
2,122
No, you are kinda missing the point.

I do already use ZFS. That's what my 20TB array is running on.

I really just want to protect my single OS disk from a disk failure so that I don't have to reconfigure a whole new Debian install if it were to die.

It's got a bunch of customization I've done over time and I don't want to have to figure it all out and do it all again.


So I figured initially I would do weekly backups of my OS disk and keep the last few so that if it failed I could restore just restore it to the replacement disk.
 

SirMaster

2[H]4U
Joined
Nov 8, 2010
Messages
2,122
I was thinking about this more last night and I think I came up with a good solution.

1. snapshot my root drive with btrfs.
2. run an incremental rsync (or btrfs send) to a btrfs backup drive every night.
3. snapshot the btrfs backup.

Anyone see any problems with this idea?

I should always have consistent backups because i'm snapshotting root before rsync, and I will always have a good backup even if a drive starts to fail because I keep snapshots of each backup every night for a month for example. So I can just restore the root fs from any day and find a day that works in case the last few backups were corrupt due to maybe rsync having trouble reading from a partially failing drive.
 
Last edited:
Top