Backing up RHEL5 and 6

Latest response


I have RHEL5 and 6. I am just now getting into redhat. So far support has been better than expected. Being thatI only have two production servers, I dont want to go all out on backup software just yet. Whats the cheapest yet reliable way to do a full system back up on my servers just in case my Errata updates go awry? Don't get me wrong they will be important production servers and I will have to test the restore method also. 




Hi Joseph,

With these servers being important production servers, I would certainly recommend a rigorous full backup regimen. What tool should you use to backup, however, is a question with many answers.

I see many customers using Symantec's NetBackup, but unfortunately I do not know the cost. An open source solution I have heard a lot about is Clonezilla, so that might be worth a look.

As far as what is shipped in RHEL5 and 6 for backup...they are pretty basic tools. From what I can think of, you essentially have `tar`, amanda, coupled with custom scripting and cron.

I think a big decision you will have to make is whether or not you would like a backup solution where the server can stay online or has to come down, and then go from there.

I hope this helps!


Bacula is an open-source enterprise-grade network backup solution. Bacula Systems SA operate on a licensing model very similar to our own, you may also choose to run the community version.

We ship the Bacula client in the Optional/Supplementary Channel as a convenience, the server requires additional setup.

You can

Mondo Rescue ( is worth a look. It can create restorable images from a live system, and I've used it for bare-metal recovery in the past.

> just in case my Errata updates go awry

For RHEL6, it's best to take an LVM snapshot of your root LV before you do a yum update (you'd need some free space in your VG for that, and then do something like an "lvcreate --snapshot --name RootSnapshot --size 2G /dev/VolGroup/Root"). Then do the update, and if it works out (you can optionally reboot to be extra sure), remove the snapshot. If the updated ended up causing an issue; just revert back to the snapshot (lvconvert --merge VolGroup/RootSnapshot) and reboot.

Of course; that's no excuse to not back up. I recommend if you have a standby server, and also recommend backing up LVM snapshots rather than the filesystem directly; along with software-specific tools if available (eg. slapcat or mysqldump). If done right, you can restore from bare-metal just with a rescue CD.

I like the flexibility of Acronis.  You can use it for Bare Metal BU/restore, P2V/V2V migrations, DR... etc...  They are currently the only ISV listed in the Red Hat Marketplace for RHEV.

An implementation that I was considering looking into (for home use) was flyback - which claims to be like Apple's TimeMachine.  Unfortunately it seems to be more Debian focused, but there are options for numerous variants.

Fedora 17 has Deja Dub Backup Tool available also - I have not used it, nor have I looked into it.  It appears to be a fairly compelling option for Amazon S3 backups - which may be a good option for you if you are not prepared to invest in an enterprise solution onsite.


Also - I don't have an exact number when I believe a customer should invest in Satellite, but if you plan on growing your environment beyond a few dozen hosts, I would highly recommend researching Red Hat Network Satellite.  It would help address the concern of errata causing issues.  Backups are obviously the safest route, but also the most impactful if you actualy need to recall a backup and restore a host.  Satellite allows you to "roll back" updates and identify what updates were applied, etc.. as well as allowing you to control what updates get applied.


you mention you only have two production rhel servers.  Are there other servers there and an existing backup solution that you might leverage? We had been an HP-UX shop and used HP Dataprotector for our Unix backups, eventually our Windows backups and finally our RHEL backups.  While it hasn't been perfect, it's been able to do what we need it to and integrates with our different databases and applications including Informix, Oracle, Exchange.  In recent years as we virtualized on VMware we've started using VEEAM.  It's a bear to use if you need to do a file level restore but otherwise seems to be a decent application.




There is no existing bakup. I have been tasked with backing up approx 6-10 servers since I last posted. I may need to look for a paid version with support to get it setup. most of out servers are RHEL456. I have downloaded clonezilla but I may need to look into something else. Symantic maybe Acronis.



There is no existing bakup. I have been tasked with backing up approx 6-10 servers since I last posted. I may need to look for a paid version with support to get it setup. most of out servers are RHEL456. I have downloaded clonezilla but I may need to look into something else. Symantic maybe Acronis.

Hi Joseph,

If you want to create a full system backup which can replace/restore in very less time, then replicating the production server disk may be a good solution for you which can be the full system backup till date you create it as you mentioned that you want cheapest but reliable way. And for incremental backups, you may use dump/restore commands.

Red Hat Enterprise Linux has an utility dd which can do the task of full replication.

[1] Suppose your system has a disk /dev/sda with 1TB storage capacity, connect another disk with the same storage capacity to the system which may be detected as /dev/sdb.

[2] Boot the machine, it will have two disks, one on which system is installed i.e. /dev/sda and another on which nothing is there i.e. raw disk /dev/sdb

[3] Copy the system image to newly attached disk.

        # dd if=/dev/sda of=/dev/sdb

This will take some time as it has to copy each and every file from the disk /dev/sda to /dev/sdb.

[4] To test the backup, remove the original disk /dev/sda and attach /dev/sdb (backed up disk) in place of /dev/sda, and see if it boots or not. If it boots, full system backup is successful.

There is are some knowledgebase Solutions depicting this method with other options such as compression with dd.


As a former NetBackup consultant and current NetBackup architect, I can tell you, without a doubt, that NetBackup is almost certainly *WAY* overkill - from both a complexity and cost standpoint - for that small a number of systems.

In your original post and followups, you never told us whether the systems you're trying to back up are physical hosts or virtual machines. You never told us anything about their overall configurations (number/size of disks, networking, etc.). Different solutions have different operational-sweetspots relative to the amount of data to back up, the number of clients to back up, the types of clients to back up,  the mix of applications to be backed up, the types of backups you want to do (fully-consistent or crash-consistent) and the resources that your clients and backup infrastructure can bring to bear.

Just to add to the pile of alternatives, since I haven't seen it mentioned yet, our shop (with many virtual RHEL[456] and Windows Server systems) just decided to license Idera which has attractive per-VM cost.  Eval available here.  Maybe it fits your needs, maybe not.

I would not recommend this method (dd); not only is it painfully inefficient, but copying a disk while the OS & services are running will result in an inconsistent & probably useless backup.

If you really need a restorable image of the server as is, use Clonezilla as mentioned before (which needs downtime as it would boot from a live CD/USB or PXE); it's much better than DD as it only backs up the used spaced with partclone by default. The difference between it and DD may be 1TB vs. 10GB, and it images small servers in a few minutes vs. hours with dd. 

Of course; Clonezilla is not really a complete backup solution (unless you are sure nothing in the server changes); it's more like something you can use to get a server up and running from the clonezilla snapshot quickly (so that all the OS configuration/partitioning is automatically done as before); and then restore the more recent data from whatever backup solution you're using.

(and if you use rsnapshot or similar backup solutions to back up LVM snapshots as I described before; you wouldn't need clonezilla if you are good enough with linux, you can do an online backup, and restore from bare-metal. You can also use Mondo as suggested here before, but I haven't use it.).

I want to say thanks to everyone. You have been very helpful. I am not a RHEL pro but novice. Atleast I can get started with the information you guys gave me. Currently we have no Virtual RHEL. I will be doing research on all that was mentioned. So far I am liking clonezilla. I am looking to use clonezilla to backup a RHEL6 server. It is in RAID Integrated Mirror. I will restore to the same machine just for testing purposes. I am looking at current videoes to backup to external HDD with clonezilla, if anyone has a particular video in mind, please feel free to foward it. You guys have been really helpful. \





Thanks for your assistance. I understand that RHEL6 comes with LVM. I like your comment and I want to start using something like LVM. 

1. I understand that I may need free space in my Volume Group to store these snapshots. My question is How do I view how much room I currently have? (lvdisplay?) and how do I know how much to allocate. I dont mind allocating too much just to ensure everything will work.

2. given the command ("lvcreate --snapshot --name RootSnapshot --size 2G /dev/VolGroup/Root") is is my understanding that I am (creating a logical volume--and it is called RootSnapshot-- 2GB in size and i am copying it to (/dev/VolGroup/Root)

reverting makes sense to me. but I just wanted to make sure about lvcreate. 


1. You can get the free space in the volume group by using "lvm vgs". By default, RHEL does not allocate free space on a VG with automatic partitioning; which is a bad thing in my opinion. If you don't have free space; you may have to consider perhaps shrinking the swap partition or something to be able to use snapshots.

2. Well, with that command, you'd be creating a snapshot of the /dev/VolGroup/Root logical volume, and naming the snapshot /dev/VolGroup/RootSnapshot. That snapshot is 2GB in size; and can hold 2GB worth of changes in the root volume before the snapshot being invalidated, so I'd recommend larger sizes (like 5-10GB) just in case, although 2GB would work with most updates

You can read about LVM snapshots in the documentation:

The "how much to allocate" is kind of a chicken/egg problem.

To know "how much to allocate" you need to know what your data change rates are for the target volumes. Some volumes will be nearly static. Other volumes may have change rates that are quite high. Without knowing your change rates, even if you think you're playing it adequately-safe, you may still come in too short.

Unfortunately, one of the easier ways to guage change-rates would  be to look a month's worth of incremental backup jobs. Incrementals only back up changed-data. Having a month's worth of information about those jobs would allow you to guague average and peak change-rates. Unfortunately, before you have that trackable backup data, you sorta have to SWAG things. On the plus side, once you do have that data, you can resize your snapshot volumes to more appropriate sizes (one that are both large enough yet not so large as to waste space)


We could perform bare metal backup/restore of the system using tar command also as described in following article, it's simple and easier to use:

"How do I backup and restore a whole Red Hat Enterprise Linux system with the dump/restore commands?"

Kind regards,