Rsnapshot -- a very elegant approach to incremental backups

• Introduction
• Installation
• Configuration
• Scheduling
• History

Introduction

Rsnapshot is a very elegant filesystem snapshot utility for making backups of local and remote systems.  It is written in Perl is a one large Perl script (~7K lines). The key idea is to use  rsync for copying files and hard links to maintaining multiple versions. If you hardlink the most recent version  (say day.0) of a file to a  new directory (say, day.1)  and then run rsync to synchronize day.0 and the target, the hardlink is automatically converted to a backup of the file.  Files that overwrite hardlink  leave old content in place.  Identical files remain hardlinked saving tremendous amount of space in case of OS backup, where using  tiny fraction of files changes from one backup to another.

It is essentially a poor man version control system that can automatically provide  you with backup of your programs and scripts. But it works for large binary trees as well  providing incremental backup at a very low cost.

The idea is very elegant and non trivial: if a file that is hardlink is updated, hardlink is broken and the second hardlink automatically became a backup.  This approach is scalable to a very large number of files as on modern filesystems it is difficult to run  out of inodes. 

"Braking hard links on update" approach allows to keep multiple, full backups instantly available but  saving space to store then probably 10 times or more.  The disk space required is just a little more than the space of one full backup, plus incremental backups.   But if incremental backups needs to restored in reverse chronological order to get a correct result, here any backup looks like full backup -- you can copy it directly.

The current implementation of Rsnapshot has the following key features

• Supports multiple levels of backup such as monthly, weekly, and daily
• Stores previous versions as actual files, while unchanged files remains hardlinks, which allows to save space
• All versions of the backup are accessible as plain files without compression.

Only rsync are required for local backups. for remote backup you need ssh in addition to rsync.

The utility is well documented. Options are mostly directly translated to rsync options. There is way to see the generated rsync command with -t option, for example

rsnapshot -t hourly

Along with man page there is the rsnapshot HOWTO. The HOWTO will give you a detailed walk-through on how to get rsnapshot up and running in explicit detail.

There is also FAQ FAQ rsnapshot

Installation

All major distros have Rsnapshot already packaged. Here are a few links:

• ArchLinux
• Debian
• Fedora
• Gentoo Linux
• Ubuntu
• FreeBSD
• NetBSD
• OpenBSD

On RHEL installation is possible via RPM.  But in general as this Perl script you can install it yourself without any RPM.

There is an extension with GUI called Rsnap.

Configuration

The first step after the installation is to configure /etc/rsnapshort.conf.

Attention: you editor should not convert tabs into spaces: configuration file requires tabs.

Here is a very simple example when you backup the whole root filesystem on a  flash drive

[root@centos68 ~]# egrep -v "^#" /etc/rsnapshot.conf

config_version  1.2
snapshot_root   /media/Seagate/.snapshots
cmd_rm          /bin/rm
cmd_rsync       /usr/bin/rsync
cmd_logger      /usr/bin/logger
retain  daily   30
retain  monthly 12
verbose         2
loglevel        3
lockfile        /var/run/rsnapshot.pid
one_fs          1
exclude		/proc
exclude		/sys
backup  	/	/home/

There is a couple of gotcha here:

• Fields in config file should be separated by tab (which was pretty stupid decision for the script written in Perl).  To test your config file for this and other errors run  rsnapshot configtest
• Backup levels names should be in ascending order. In Red Hat rpm that installed on Red Hat 6.x backups levels are named apha, beta, gamma.  To preserve sanity, it might make sense to restore to proper labels like daily/weekly or daily/monthly 

  NOTE: As the labels should in ascending order, so daily, weekly, monthly  will NOT work, but  B1_daily, B2_weekly, B3_monthly will work )

Scheduling

Typically Rsnapshot runs as root by a cron job, or, optionally,  series of cron jobs.  For example

0  4 * * *       /usr/local/bin/rsnapshot daily
0 23 1 * *       /usr/local/bin/rsnapshot monthly

It is possible, however, to run as it as arbitrary user as permissions it requires are just read/write access to target files.  Of course you can't backup OS as a regular user as you will not be able to recreate permissions.  But all you scripts and programs can be backuped this way

It is also possible to run it with an alternate configuration file. So there can be multiple cron jobs each with own configuration file.

The net result on backup media will be series of directories

[root@localhost]# ls -l /mnt/Seagate/.snapshots
drwxr-xr-x    7 root     root         4096 Dec 28 00:00 daily.0
drwxr-xr-x    7 root     root         4096 Dec 27 00:00 daily.1
drwxr-xr-x    7 root     root         4096 Dec 26 00:00 daily.2
drwxr-xr-x    7 root     root         4096 Dec 25 00:00 daily.3
drwxr-xr-x    7 root     root         4096 Dec 24 00:00 daily.4
drwxr-xr-x    7 root     root         4096 Dec 23 00:00 daily.5
drwxr-xr-x    7 root     root         4096 Dec 22 00:00 daily.6
... ... 

Inside each of these directories is a "full" backup of that point in time but it borrows pre-existing files via hardlinks which saves a lot of space.  The destination directory paths you specified under the backup keyword in the configuration file.

The directory in which that will be create is $RSNAPSHOT_HOME, which by default is /.snapshot):

backup          /etc/           localhost/

If you specified just /etc directory for your backup, the /etc/ directory will initially get backed up into /.snapshots/hourly.0/localhost/etc/

History

The original article by Mark Rubel (that inspired rsnapshot) Easy Automated Snapshot-Style Backups with Rsync (2004) contains some interesting information. One such tip is how to have backup mounted rw for root and read-only for regular users

Making the backup as read-only as possible

In the previous section, we discussed ways to keep your backup data physically separate from the data they're backing up. In this section, we discuss the other side of that coin--preventing user processes from modifying backups once they're made.

We want to avoid leaving the snapshot backup directory mounted read-write in a public place. Unfortunately, keeping it mounted read-only the whole time won't work either--the backup process itself needs write access. The ideal situation would be for the backups to be mounted read-only in a public place, but at the same time, read-write in a private directory accessible only by root, such as /root/snapshot.

There are a number of possible approaches to the challenge presented by mounting the backups read-only. After some amount of thought, I found a solution which allows root to write the backups to the directory but only gives the users read permissions. I'll first explain the other ideas I had and why they were less satisfactory.

It's tempting to keep your backup partition mounted read-only as /snapshot most of the time, but unmount that and remount it read-write as /root/snapshot during the brief periods while snapshots are being made. Don't give in to temptation!.

Bad: mount/umount

A filesystem cannot be unmounted if it's busy -- that is, if some process is using it. The offending process need not be owned by root to block an unmount request. So if you plan to umount the read-only copy of the backup and mount it read-write somewhere else, don't -- any user can accidentally (or deliberately) prevent the backup from happening. Besides, even if blocking unmounts were not an issue, this approach would introduce brief intervals during which the backups would seem to vanish, which could be confusing to users.

Better: mount read-only most of the time

A better but still-not-quite-satisfactory choice is to remount the directory read-write in place:

mount -o remount,rw /snapshot
[ run backup process ]
mount -o remount,ro /snapshot

Now any process that happens to be in /snapshot when the backups start will not prevent them from happening. Unfortunately, this approach introduces a new problem--there is a brief window of vulnerability, while the backups are being made, during which a user process could write to the backup directory. Moreover, if any process opens a backup file for writing during that window, it will prevent the backup from being remounted read-only, and the backups will stay vulnerable indefinitely.

Tempting but doesn't seem to work: the 2.4 kernel's mount --bind

Starting with the 2.4-series Linux kernels, it has been possible to mount a filesystem simultaneously in two different places. "Aha!" you might think, as I did. "Then surely we can mount the backups read-only in /snapshot, and read-write in /root/snapshot at the same time!"

Alas, no. Say your backups are on the partition /dev/hdb1. If you run the following commands,

mount /dev/hdb1 /root/snapshot
mount --bind -o ro /root/snapshot /snapshot

then (at least as of the 2.4.9 Linux kernel--updated, still present in the 2.4.20 kernel), mount will report /dev/hdb1 as being mounted read-write in /root/snapshot and read-only in /snapshot, just as you requested. Don't let the system mislead you!

It seems that, at least on my system, read-write vs. read-only is a property of the filesystem, not the mount point. So every time you change the mount status, it will affect the status at every point the filesystem is mounted, even though neither /etc/mtab nor /proc/mounts will indicate the change.

In the example above, the second mount call will cause both of the mounts to become read-only, and the backup process will be unable to run. Scratch this one.

Update: I have it on fairly good authority that this behavior is considered a bug in the Linux kernel, which will be fixed as soon as someone gets around to it. If you are a kernel maintainer and know more about this issue, or are willing to fix it, I'd love to hear from you!

My solution: using NFS on localhost

This is a bit more complicated, but until Linux supports mount --bind with different access permissions in different places, it seems like the best choice. Mount the partition where backups are stored somewhere accessible only by root, such as /root/snapshot. Then export it, read-only, via NFS, but only to the same machine. That's as simple as adding the following line to /etc/exports:

/root/snapshot 127.0.0.1(secure,ro,no_root_squash)

then start nfs and portmap from /etc/rc.d/init.d/. Finally mount the exported directory, read-only, as /snapshot:

mount -o ro 127.0.0.1:/root/snapshot /snapshot

And verify that it all worked:

mount
...
/dev/hdb1 on /root/snapshot type ext3 (rw)
127.0.0.1:/root/snapshot on /snapshot type nfs (ro,addr=127.0.0.1)

At this point, we'll have the desired effect: only root will be able to write to the backup (by accessing it through /root/snapshot). Other users will see only the read-only /snapshot directory. For a little extra protection, you could keep mounted read-only in /root/snapshot most of the time, and only remount it read-write while backups are happening.

Damian Menscher pointed out this CERT advisory which specifically recommends against NFS exporting to localhost, though since I'm not clear on why it's a problem, I'm not sure whether exporting the backups read-only as we do here is also a problem. If you understand the rationale behind this advisory and can shed light on it, would you please contact me? Thanks!

NEWS CONTENTS

• 20210324 : How To Setup Backup Server Using Rsnapshot by Senthil Kumar ( Apr 13, 2017 , ostechnix.com )
• 20210324 : rsnapshot ( rsnapshot, )
• 20170715 : How To Backup Your Entire Linux System Using Rsync ( Apr 25, 2017 , ostechnix.com )
• 20081121 : rsnapshot - Local-Remote Filesystem backups utility in openSUSE SUSE & openSUSE ( October 4, 2008 )

Old News ;-)

[Mar 24, 2021] How To Setup Backup Server Using Rsnapshot by Senthil Kumar

Apr 13, 2017 | ostechnix.com

... ... ...

Now, edit rsnapshot config file using command:

$ sudo nano /etc/rsnapshot.conf

The default configuration should just work fine. All you need to to define the backup directories and backup intervals.

First, let us setup the Root backup directory i.e We need to choose the directory where we want to store the file system back ups. In our case, I will store the back ups in /rsnapbackup/ directory.

https://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-6701402139964678&output=html&h=280&adk=2935052334&adf=2291697075&pi=t.aa~a.4159015635~i.80~rp.4&w=780&fwrn=4&fwrnh=100&lmt=1616633116&num_ads=1&rafmt=1&armr=3&sem=mc&pwprc=8125749717&psa=1&ad_type=text_image&format=780x280&url=https%3A%2F%2Fostechnix.com%2Fsetup-backup-server-using-rsnapshot-linux%2F&flash=0&fwr=0&pra=3&rh=195&rw=779&rpe=1&resp_fmts=3&wgl=1&fa=27&adsid=ChAI8MbrggYQlaj876O1srwUEioAzRwCZrDRDgBUvrQaW5GbXDwh86QENBlw-v7-PR-7DnhX3_cVwCq2ufI&dt=1616633105357&bpp=3&bdt=1341&idt=3&shv=r20210322&cbv=r20190131&ptt=9&saldr=aa&abxe=1&cookie=ID%3De131ae5ed4aa45d7-22a89a6e0dc7000a%3AT%3D1616631806%3ART%3D1616631806%3AS%3DALNI_MYN9WDd7gGVc8V-I7ZewIJezifOTg&prev_fmts=728x90%2C780x280%2C340x280%2C0x0%2C780x280%2C780x280%2C780x280&nras=5&correlator=877677215578&frm=20&pv=1&ga_vid=1440358310.1616631807&ga_sid=1616633105&ga_hid=2128223842&ga_fc=0&u_tz=-240&u_his=2&u_java=0&u_h=864&u_w=1536&u_ah=864&u_aw=1536&u_cd=24&u_nplug=3&u_nmime=4&adx=175&ady=5878&biw=1519&bih=762&scr_x=0&scr_y=2900&eid=31060287%2C44738185%2C44739387&oid=3&psts=AGkb-H_3MfY9AQf3__CNSVyjoDCpYu_ZaKaiHYqFHQ1wQJDCJhk-2CFzgXs7lxCtimCs29RaZoqMJvVRxIA%2CAGkb-H9jFVqbzgOeUl3vj0ufHziiJDG88wHSpYyHea1_SuZgYgku_spXI7u_Mw5lq5Lx3672kLVBHMXw5w%2CAGkb-H8awkyuv_oJsZhhOe9IPjgFhtTwqlJq7XJ6gfvkEWF40FhbHLmHilOFpHgD-K83h1G7n8vaRUTehfg%2CAGkb-H_ckOyStZCDLNTeIVabiCebw66dSIyH-MfyFZiH6pq4r1inFyrp81fGuJNHKRHVUVrMh_XNbpv-MLw%2CAGkb-H9SM9DZZmFihNrYkWRPSzDdb43TR0v35Yg8f_jeA4jEtFAhWB2AT2V1ONIP_oGSOumj3xM3sJE4GV43sQ%2CAGkb-H9SuZhdVHNjd3JIq9uWz6juU33Nlwy5JKxcDxmnxl-AC1GFKkElCoVRPBCv17-xB6hWLjhR0FtouuW-vw&pvsid=2810665002744857&pem=289&ref=https%3A%2F%2Fostechnix.com%2Fcategory%2Fbackup-tools%2F&rx=0&eae=0&fc=384&brdim=1536%2C0%2C1536%2C0%2C1536%2C0%2C1536%2C864%2C1536%2C762&vis=1&rsz=%7C%7Cs%7C&abl=NS&fu=8320&bc=31&jar=2021-03-20-21&ifi=8&uci=a!8&btvi=5&fsb=1&xpc=Z7XUbAeR7w&p=https%3A//ostechnix.com&dtd=10931

# All snapshots will be stored under this root directory.
#
snapshot_root   /rsnapbackup/

Again, you should use TAB key between snapshot_root element and your backup directory.

Scroll down a bit, and make sure the following lines (marked in bold) are uncommented:

[...]
#################################
# EXTERNAL PROGRAM DEPENDENCIES #
#################################

# LINUX USERS: Be sure to uncomment "cmd_cp". This gives you extra features.
# EVERYONE ELSE: Leave "cmd_cp" commented out for compatibility.
#
# See the README file or the man page for more details.
#
cmd_cp /usr/bin/cp

# uncomment this to use the rm program instead of the built-in perl routine.
#
cmd_rm /usr/bin/rm

# rsync must be enabled for anything to work. This is the only command that
# must be enabled.
#
cmd_rsync /usr/bin/rsync

# Uncomment this to enable remote ssh backups over rsync.
#
cmd_ssh /usr/bin/ssh

# Comment this out to disable syslog support.
#
cmd_logger /usr/bin/logger

# Uncomment this to specify the path to "du" for disk usage checks.
# If you have an older version of "du", you may also want to check the
# "du_args" parameter below.
#
cmd_du /usr/bin/du

[...]

Next, we need to define the backup intervals:

#########################################
# BACKUP LEVELS / INTERVALS #
# Must be unique and in ascending order #
# e.g. alpha, beta, gamma, etc. #
#########################################

retain alpha 6
retain beta 7
retain gamma 4
#retain delta 3

Here, retain alpha 6 means that every time rsnapshot alpha run, it will make a new snapshot, rotate the old ones, and retain the most recent six (alpha.0 - alpha.5). You can define your own intervals. For more details, refer the rsnapshot man pages.

https://googleads.g.doubleclick.net/pagead/ads?client=ca-pub-6701402139964678&output=html&h=280&adk=2935052334&adf=1889294700&pi=t.aa~a.4159015635~i.94~rp.4&w=780&fwrn=4&fwrnh=100&lmt=1616633121&num_ads=1&rafmt=1&armr=3&sem=mc&pwprc=8125749717&psa=1&ad_type=text_image&format=780x280&url=https%3A%2F%2Fostechnix.com%2Fsetup-backup-server-using-rsnapshot-linux%2F&flash=0&fwr=0&pra=3&rh=195&rw=779&rpe=1&resp_fmts=3&wgl=1&fa=27&adsid=ChAI8MbrggYQlaj876O1srwUEioAzRwCZrDRDgBUvrQaW5GbXDwh86QENBlw-v7-PR-7DnhX3_cVwCq2ufI&dt=1616633105367&bpp=2&bdt=1351&idt=2&shv=r20210322&cbv=r20190131&ptt=9&saldr=aa&abxe=1&cookie=ID%3De131ae5ed4aa45d7-22a89a6e0dc7000a%3AT%3D1616631806%3ART%3D1616631806%3AS%3DALNI_MYN9WDd7gGVc8V-I7ZewIJezifOTg&prev_fmts=728x90%2C780x280%2C340x280%2C0x0%2C780x280%2C780x280%2C780x280%2C780x280&nras=6&correlator=877677215578&frm=20&pv=1&ga_vid=1440358310.1616631807&ga_sid=1616633105&ga_hid=2128223842&ga_fc=0&u_tz=-240&u_his=2&u_java=0&u_h=864&u_w=1536&u_ah=864&u_aw=1536&u_cd=24&u_nplug=3&u_nmime=4&adx=175&ady=7945&biw=1519&bih=762&scr_x=0&scr_y=4898&eid=31060287%2C44738185%2C44739387&oid=3&psts=AGkb-H_3MfY9AQf3__CNSVyjoDCpYu_ZaKaiHYqFHQ1wQJDCJhk-2CFzgXs7lxCtimCs29RaZoqMJvVRxIA%2CAGkb-H9jFVqbzgOeUl3vj0ufHziiJDG88wHSpYyHea1_SuZgYgku_spXI7u_Mw5lq5Lx3672kLVBHMXw5w%2CAGkb-H8awkyuv_oJsZhhOe9IPjgFhtTwqlJq7XJ6gfvkEWF40FhbHLmHilOFpHgD-K83h1G7n8vaRUTehfg%2CAGkb-H_ckOyStZCDLNTeIVabiCebw66dSIyH-MfyFZiH6pq4r1inFyrp81fGuJNHKRHVUVrMh_XNbpv-MLw%2CAGkb-H9SM9DZZmFihNrYkWRPSzDdb43TR0v35Yg8f_jeA4jEtFAhWB2AT2V1ONIP_oGSOumj3xM3sJE4GV43sQ%2CAGkb-H9SuZhdVHNjd3JIq9uWz6juU33Nlwy5JKxcDxmnxl-AC1GFKkElCoVRPBCv17-xB6hWLjhR0FtouuW-vw%2CAGkb-H_vc2WdY5H-Moj-ezEu7IDslUkOhKidPtG9RNqCgdFTwDB78MvRCqHwatWcUx6zfLcmgkpZDH-Ssas&pvsid=2810665002744857&pem=289&ref=https%3A%2F%2Fostechnix.com%2Fcategory%2Fbackup-tools%2F&rx=0&eae=0&fc=384&brdim=1536%2C0%2C1536%2C0%2C1536%2C0%2C1536%2C864%2C1536%2C762&vis=1&rsz=%7C%7Cs%7C&abl=NS&fu=8320&bc=31&jar=2021-03-20-21&ifi=9&uci=a!9&btvi=6&fsb=1&xpc=DkVUC47tnJ&p=https%3A//ostechnix.com&dtd=16546

Next, we need to define the backup directories. Find the following directives in your rsnapshot config file and set the backup directory locations.

###############################
### BACKUP POINTS / SCRIPTS ###
###############################

# LOCALHOST
backup /root/ostechnix/ server/

Here, I am going to backup the contents of /root/ostechnix/ directory and save them in /rsnapbackup/server/ directory. Please note that I didn't specify the full path (/rsnapbackup/server/ ) in the above configuration. Because, we already mentioned the Root backup directory earlier.

Likewise, define the your remote client systems backup location.

# REMOTEHOST
backup [email protected]:/home/sk/test/ client/

Here, I am going to backup the contents of my remote client system's /home/sk/test/ directory and save them in /rsnapbackup/client/ directory in my Backup server. Again, please note that I didn't specify the full path (/rsnapbackup/client/ ) in the above configuration. Because, we already mentioned the Root backup directory before.

Save and close /ect/rsnapshot.conf file.

Once you have made all your changes, run the following command to verify that the config file is syntactically valid.

rsnapshot configtest

If all is well, you will see the following output.

Syntax OK

Testing backups

Run the following command to test backups.

rsnapshot alpha

This take a few minutes depending upon the size of back ups.

Verifying backups

Check the whether the backups are really stored in the Root backup directory in the Backup server.

ls /rsnapbackup/

You will see the following output:

alpha.0

Check the alpha.0 directory:

ls /rsnapbackup/alpha.0/

You will see there are two directories automatically created, one for local backup (server), and another one for remote systems (client).

client/ server/

Check the client system back ups:

ls /rsnapbackup/alpha.0/client

Check the server system(local system) back ups:

ls /rsnapbackup/alpha.0/server

Automate back ups

You don't/can't run the rsnapshot command to make backup every time. Define a cron job and automate the backup job.

sudo vi /etc/cron.d/rsnapshot

Add the following lines:

0 */4 * * *     /usr/bin/rsnapshot alpha
50 23 * * *     /usr/bin/rsnapshot beta
00 22 1 * *     /usr/bin/rsnapshot delta

The first line indicates that there will be six alpha snapshots taken each day (at 0,4,8,12,16, and 20 hours), beta snapshots taken every night at 11:50pm, and delta snapshots will be taken at 10pm on the first day of each month. You can adjust timing as per your wish. Save and close the file.

Done! Rsnapshot will automatically take back ups on the defined time in the cron job. For more details, refer the man pages.

man rsnapshot

That's all for now. Hope this helps. I will soon here with another interesting guide. If you find this guide useful, please share it on your social, professional networks and support OSTechNix.

Cheers!

rsnapshot

Official website

rsnapshot is a filesystem snapshot utility based on rsync. rsnapshot makes it easy to make periodic snapshots of local machines, and remote machines over ssh. The code makes extensive use of hard links whenever possible, to greatly reduce the disk space required.

Depending on your configuration, it is quite possible to set up in just a few minutes. Files can be restored by the users who own them, without the root user getting involved.

There are no tapes to change, so once it's set up, your backups can happen automatically untouched by human hands. And because rsnapshot only keeps a fixed (but configurable) number of snapshots, the amount of disk space used will not continuously grow.

It is written entirely in Perl with no module dependencies, and has been tested with versions 5.004 through 5.16.3. It should work on any reasonably modern UNIX compatible OS.

rsnapshot was originally based on an article called Easy Automated Snapshot-Style Backups with Linux and Rsync, by Mike Rubel.

If this is your first experience with rsnapshot, you may want to read the rsnapshot HOWTO at http://www.rsnapshot.org/ . The HOWTO will give you a detailed walk-through on how to get rsnapshot up and running in explicit detail.

rsnapshot comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public Licence for details.

[Jul 15, 2017] How To Backup Your Entire Linux System Using Rsync

Apr 25, 2017 | ostechnix.com

First, insert your backup medium (Pend drive or External hard disk). Then find the drive letter using 'fdisk -l' command. In my case, my Pen drive id is /dev/sdb1. Mount your drive to any location of your choice.

sudo mount /dev/sdb1 /mnt

To backup the entire system, all you have to do is open your Terminal and run the following command as root user:

sudo rsync -aAXv / --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} /mnt

This command will backup the entire / directory, excluding /dev, /proc, /sys, /tmp, /run, /mnt, /media, /lost+found directories.

Let us break down the above command and see what each argument does.

• rsync – A fast, versatile, local and remote file-copying utility
• -aAXv – The files are transferred in "archive" mode, which ensures that symbolic links, devices, permissions, ownerships, modification times, ACLs, and extended attributes are preserved.
• / – Source directory
• –exclude – Excludes the given directories from backup.
• /mnt – It is the backup destination folder.

Please be mindful that you must exclude the destination directory, if it exists in the local system. It will avoid the an infinite loop.

[Nov 21, 2008] rsnapshot - Local-Remote Filesystem backups utility in openSUSE SUSE & openSUSE

Perl codebase might be reused.

October 4, 2008

rsnapshot is a filesystem backup utility based on rsync. Using rsnapshot, it is possible to take snapshots of your filesystems at different points in time. Using hard links, rsnapshot creates the illusion of multiple full backups, while only taking up the space of one full backup plus differences. When coupled with ssh, it is possible to take snapshots of remote filesystems as well.

rsnapshot is written in Perl, and depends on rsync. OpenSSH, GNU cp, GNU du, and the BSD logger program are also recommended, but not required. rsnapshot is written with the lowest common denominator in mind. It only requires at minimum Perl 5.004 and rsync. As a result of this, it works on pretty much any UNIX-like system you care to throw at it.

rsnapshot can run almost out of the box with very little configuration changes although advanced configurations can be done with little more effort.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

General

• rsnapshot-rsnapshot- a tool for backing up your data using rsync (if you want to get help, use https---lists.sourceforge.net-lists-listinfo-rsnapshot-discuss)
  • rsnapshot-docs-HOWTOs at master · rsnapshot-rsnapshot · GitHub
• FAQ rsnapshot
• rsnapshot(1) - Linux man page
• rsnapshot › Wiki › ubuntuusers.de
• rsnapshot-diff(1) - Linux man page
• Rsnapshot - QNAPedia

Distribution specific pages

• rsnapshot - ArchWiki ArchWiki integrated Rsnapshot into systemd
• Debian - Ubuntu Linux Install and Configure Remote Filesystem Snapshot with rsnapshot Incremental Backup Utility
• A simple backup scheme using rsnapshot - Gentoo Wiki -- this is helpful article with practical recommendations.
• rsnapshot - Mailing Lists
• Easy Automated Snapshot-Style Backups with Rsync

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: September, 01, 2020