RDX is a disk technology that puts small 2.5“ disk drives into hardened cases. It's meant to operate in place of tape. However, it has several advantages over tape. Linux supports RDX both in their USB and SATA variants. RDX drives simply show up as SATA disk drives or USB mass storage disk drives.

To create a full backup of your Linux system you have a number of options. Here are several.

• Use the dump utility to do a file based backup of each file system.
• Use an archiver like tar, cpio, or pax to perform a file backup of one or all of your file systems
• Use a bare metal recovery tool like Acronis TrueImage, Linux Relax-and-Recover, PartImage, or Clonezilla.
• Take a 1:1 clone using dd

There are several pros and cons to each method. We'll cover the just-use-the-system-tools methods and leave the big tool suites like Acronis alone. Each of the big cloning/backup packages has their own documentation.

The dump utility isn't just one thing. It's several utilities. Each one is paired with the filesystem that it's made to dump. Usually the same developers who write the filesystem implementation will also write a dump utility. What's nice about dump is that, since it's tailor made for the filesystem, it's sure to grab all the metadata it needs for a full reconstruction.

Advantages of using dump:

• Fast transfer speeds.
• Very safe option, usually written by the filesystem maintainers. Gets all the quirky metadata.
• Well proven over many years. Very reliable.
• Gives good progress & status as it runs and estimates a completion time (usually).
• Easily integrates multi-volume dumps to tapes or multiple files.
• Has a nice interactive restore feature that's easy to use.
• Allows you to restore to different sized filesystems or even different types of filesystems.

Drawbacks of using dump:

• Cannot re-install your boot loader. You still have to do that manually when you want to recover the bare metal machine.
• Can only work with local filesystems. Dump often refuses to work with NFS or foreign filesystems.
• Most dump utilities don't have built-in compression, but that's not really a drawback, just an extra step.

So, how does one use dump? Well, for starters the man page is the best reference for it. Keep in mind dump will work against a raw device like a tape drive or RDX drive just as easily as it will to a file on a file system. So, you really have two choices:

1. Dump straight to your RDX as if it was a tape drive.
2. Create a filesystem on your RDX, mount it, and then dump to a file on the RDX.

The first method is more simple and mimics how tape drives work for those really used to tape. The second is more friendly to someone who might come along later and wonder what is on that drive. The second method also gives you the option to compress the dump before writing it to the filesystem. That's more complicated and makes things that much more opaque if you use compression with a direct-to-device dump. So, for most folks, I'd recommend going ahead with using a filesystem as it provides better clarity and usability with compression. Another big drawback is that you'd need to use some kind of tape marker to separate backups if you wanted to take more than one using the no-filesystem method.

Say you want to dump using a file system on your RDX drive. Here is an overview of the process.

1. Make sure you know what filesystems you are dumping. If it's for a bare metal backup, we'll definitely need the root (/), /usr, /var, and any other operating system required file systems you might have split out during installation of your OS. In many cases the system disk is going to be /dev/sda but not always. Look at the output of mount and check your /etc/fstab file to see what is mounted and where.
2. Make sure you know which drive is your RDX drive. Usually you can tell by looking at the boot (ring buffer) messages by typing dmesg. However, that doesn't always work because sometimes those messages get overwritten or disappear. So, you can also review the fdisk -l output which shows all disks, sizes, and partition layout. Look for a disk the size of your RDX. You might also want to look at the output of ls /dev/disk/by-id which may reveal more information about your disk layout.
3. Make sure your data will fit on the device. If you are backing up a larger hard drive to a smaller RDX, do some math and make sure the dump file will fit on the RDX. If not, consider using compression in a pipeline.

## find out which is my local root file system
$ mount

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=4114461,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3293532k,mode=755)
/dev/mapper/pve-root on / type ext3 (rw,user_xattr,acl,barrier=0)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=6587060k)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
/dev/mapper/pve-data on /var/lib/vz type ext3 (rw,relatime)
/dev/sda2 on /boot type ext3 (rw,user_xattr,acl,barrier=0,data=ordered)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)

## Find my RDX drive 
fdisk -l 

## You might see something like this if you had a 146 gig root disk
## and a 1TB RDX drive: 

Disk /dev/sda: 146.2 GB, 146163105792 bytes
255 heads, 63 sectors/track, 17769 cylinders, total 285474816 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000787a8

## Looks like the RDX 1TB disk is /dev/sdb so, put a linux partition on it
fdisk /dev/sda
## If the disk has partitions you want to delete, do so with "d"
## Then use "n" for new partition and take the defaults. It defaults to Linux
## then hit "w" to save/write and quit from fdisk. 

## Now make a filesystem on the linux partition. 
mkfs /dev/sda1

## Now we mount the partition
mkdir /backup
mount /dev/sda1 /backup

## Now we perform the dumps on every filesystem that matters to us
dump -0f /backup/mybackup_root.dump /
dump -0f /backup/mybackup_boot.dump /boot
dump -0f /backup/mybackup_usr.dump /usr

This is a similar process as using a filesystem without the partitioning and mounting step. So, having gone over some of the process, I'll condense this example somewhat.

## Double check my filesystems so I know what I'm dumping
$ mount

## Find my RDX Drive by exploring the drives on the system
fdisk -l
ls /dev/disk/by-id

## Perform the dump straight to the RDX without mounting it. 
## in this case, my RDX was found to be /dev/sdb and I ignore
## any partitions on it, going straight to the raw device
dump -0f /dev/sdb /

## Remember we can only dump one filesystem unless we use tape marks.
## so don't use this method unless really know what you are doing. 

Tar (and by extension other file archivers like pax and cpio) can also work for system backups. Here are the pros and cons.

Advantages of using tar for backups:

• Tar is fast
• Tar is broadly compatible. You'll be able to dig into the archive with many tools on many OSes.
• Tar doesn't implement compression, leaving you free to compress tar files with anything you want
• It can go direct to a tape or disk device like dump but it also to a file.

Drawbacks of using tar for system backups:

• Tar doesn't do estimates of when it'll complete. It just goes and goes sequentially until done.
• Tar isn't as pedantic about weird files like named-pipes or FIFO files. It might not archive them as well as dump but most people don't care and don't need that to work anyway as most of those types of files are created dynamically.
• By default, tar won't care if it crosses a filesystem boundry. This can cause problems and I recommend you use the –mount or –xdev flags when doing system backups to avoid this issue. Backup the filesystems separately or use exclude lists
• Tar isn't smart enough to automatically avoid synthetic filesytems like /proc or /sys, or

For doing system backups there are two things I recommend you do that are not tar's default behavior.

1. Do not let it cross file systems.
2. Do not let it backup in-memory filesystems like /proc

So, in my example, let's say I have three critical filesystems that are part of my OS build. They are /, /usr, and /home. I want to dump them to an RDX with a filesystem because I don't want to fiddle with any direct-to-device backups. Here goes.

## Double check my filesystems so I know what I'm dumping
$ mount

## Find my RDX Drive by exploring the drives on the system
fdisk -l
ls /dev/disk/by-id

## Put a partition on the RDX drive, in this case /dev/sdb
fdisk /dev/sdb
## If the disk has partitions you want to delete, do so with "d"
## Then use "n" for new partition and take the defaults. It defaults to Linux
## then hit "w" to save/write and quit from fdisk. 

## Put a filesystem on the partition
mkfs /dev/sdb1

## Mount the RDX filesystem on the /backup directory
mount /dev/sdb1 /backup

## Perform the tar backups one FS at a time using GZIP compression
tar -c --one-file-system -vzf /backup/root_backup.tar.gz /
tar -c --one-file-system -vzf /backup/usr_backup.tar.gz /usr
tar -c --one-file-system -vzf /backup/home_backup.tar.gz /home