Rsnapshot

rnapshot is an excellent backup application and has been around for a long time and is extremely stable.

Why are backups important? Well, hardware failures, accidental file deletion(s), files become corrupted, etc.. Backups can help recover data where applications are being updated/upgraded. Enough reasons?

Where should backups be stored? Due to the inevitable failure of hardware it is desirable to store backups on a separate system from where the production data is stored. Or possibly to an external medium such as an external USB disk drive. This article discusses backing up to an external USB drive.

Please Note:

rnapshot depends on attributes that are unique to Linux/Unix (i.e. ext3, ext4) filesystems only. If backups to "CIFS" (Samba a.k.a. smb, fat, fat32, vfat, ntfs) filesystems are required a different backup application must be used (i.e. rdiff-backup).

Here is a good book that discusses backups, recoveries, rsnapshot and rdiff-backup: "Backup & Recovery: Inexpensive Backup Solutions for Open Systems, by W. Curtis Preston".

Preparing an External USB Drive

Off-the-shelf external USB drives normally are setup to work with computers that utilize CIFS type filesystems. rsnapshot uses a "hard links" feature that is unique to Linux/Unix filesystems (ext3). "Hard Links" are not supported on filesystems such as: "smbfs", "Samba (SMB)", "FAT", "FAT32", "NTFS", "CIFS", "vfat". Please note that "Amahi Greyhole" mounts Amahi shares that will look like "local disk drives" but these are Samba (SMB) mounted shares. An external disk drive will have to be prepared for a Linux/Unix filesystem, in particular ext3. Why? ext3 has been around for sometime, is stable, and "Windows" computers have Open Source drivers available that can be installed to gain access to an ext3 drive.

Prepare an external drive for ext3 as follows:

• The external USB drive used in this example is a 1 Terabyte (1 TB) Seagate drive.
• Plug the drive in to a USB connector and power it up.
• Using a "terminal" session, login in using the "root" user ID.
• The "device name" of the drive needs to be determined.

Enter the following command:

bash code
​dmesg​

The following information is displayed:

Text
​[11122.304178] usb 2-4: new high-speed USB device number 5 using ehci_hcd [11122.422152] usb 2-4: New USB device found, idVendor=0bc2, idProduct=3320 [11122.422165] usb 2-4: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [11122.422173] usb 2-4: Product: Expansion Desk [11122.422180] usb 2-4: Manufacturer: Seagate . . . . . [11123.516813] sdb: sdb1​

• The "device name" is "sdb1".
• The USB drive needs to be "unmounted".

bash code
​umount /dev/sdb1​

• Format drive for ext3 filesystem and set drive label name as "usbdisk".

bash code
​mkfs -t ext3 -v -L usbdisk /dev/sdb1​

Please Note: THIS WILL ERASE ALL DATA ON /dev/sdb1, MAKE SURE THIS IS THE CORRECT USB DRIVE AND NOT ANOTHER DRIVE.

The following information is displayed:

Text
​mke2fs 1.42.5 (29-Jul-2012) fs_types for mke2fs.conf resolution: 'ext3' Filesystem label=usbdisk OS type: Linux . . . . . Writing superblocks and filesystem accounting information: done​

• Whenever a drive is formatted in Linux, about 5% is reserved of the total space on the drive for the operating system to continue using the hard drive to operate, even if it gets full. This is totally unnecessary for a USB external hard drive if it stores only data and not to run an operating system.

Enter the following to remove the reserved space:

bash code
​tune2fs -m 0 /dev/sdb1​

The following information is displayed:

Text
​tune2fs 1.42.5 (29-Jul-2012) Setting reserved blocks percentage to 0% (0 blocks)​

• The external drive is now ready for use.

Mounting an External USB Drive

There are two methods of mounting an external USB drive. The first, mounts the drive automatically each time the server "boots" or "reboots". The second, is mounted manually by the "root" user via the "command-line".

Before proceeding a couple of information items need to be gathered:

• In the previous section the device name found found via the "dmesg" command. The device name found was "sdb1".
• We set the set the external drive's "label". It was set to "usbdisk".

To find the label at anytime via the "root" user ID enter:

bash code
​e2label /dev/sdb1​

The following information is displayed:

Text
​usbdisk​

Both methods of mounting will be controlled by the server's "fstab" configuration file. The fstab (a.k.a file systems table) file is a system configuration file containing lists of available disks and disk partitions, and indicates how they are to be initialized or otherwise integrated into a system's file system. When the "mount" command is used, the fstab file is read to determine which options should be used when mounting a specified device.

Auto-Mounting

To Auto-mount your usbdisk (so the backup will work after a reboot) do the following:

cp /etc/fstab /etc/fstab_bak

nano /etc/fstab

Add to this file

LABEL=usbdisk /media/usbdisk ext3 defaults 0 0

Save the file.

Manual Mounting

< TBA >

Install rsnapshot

yum install rsnapshot

mkdir -p /media/usbdisk/.private/.snapshots

chmod 0700 /media/usbdisk/.private/

chmod 0755 /media/usbdisk/.private/.snapshots/

Configuring rsnapshot

nano /etc/rsnapshot.conf

make the following modifications to the file rsnapshot.conf for blank spaces use TABS!

snapshot_root /media/usbdisk/.private/.snapshots/

no_create_root 1

interval hourly 6

interval daily 7

interval weekly 4

interval monthly 12

verbose 3

backup /var/hda/files/docs/ localhost/

backup /var/hda/files/pictures/ localhost/

backup /var/hda/files/movies/ localhost/

backup /var/hda/files/music/ localhost/

backup /var/hda/files/othersharesyoumade localhost/

Save the file

rsnapshot configtest

this should return: syntax OK

Email reporting

for email reporting on your backups:

cp /usr/share/doc/rsnapshot*/utils/rsnapreport.pl /root

chmod 744 rsnapreport.pl

Automate backup with cronjob

crontab -l > cronjobs

nano cronjobs

add to this file for running rsnapshot and a weekly email report on rsnapshot:

0 */4 * * * /usr/bin/rsnapshot hourly 2>&1 | /root/rsnapreport.pl > /root/rsnapreport

30 23 * * * /usr/bin/rsnapshot daily

00 23 * * 1 /usr/bin/rsnapshot weekly

30 22 1 * * /usr/bin/rsnapshot monthly

00 22 * * 6 /usr/bin/rsnapshot du >> /root/rsnapreport | nail –r "somereturnadress@provider.com" -s"HDA backup report" -S smtp=smtp.yourprovider.com youremail@provider.com < /root/rsnapreport

Save the file

crontab cronjobs

Rsnapshot should now be operational.

Make your backups available on clients (READ ONLY)

If you want to make the backups accesible from your clients:

Create a //hda/backup share in the HDA webinterface

chkconfig nfs --level 2345 on

add a read only NFS export:

nano /etc/exports

add

/media/usbdisk/.private/.snapshots/ 127.0.0.1(ro,no_root_squash)

Save file

Unfortunately mounting an NFS share in fstab did not work on my machine after a reboot, so I chose an alternative configuration that mounts the share later in the booting process:

nano /etc/rc.local

Add

mount -r -t nfs localhost:/media/usbdisk/.private/.snapshots/ /var/hda/files/backup/

save file