5
:Author: Nathan Rosenquist <nathan@rsnapshot.org>
7
:Copyright: 2005 Nathan Rosenquist
10
rsnapshot is a filesystem backup utility based on rsync. Using
11
rsnapshot, it is possible to take snapshots of your filesystems at
12
different points in time. Using hard links, rsnapshot creates the
13
illusion of multiple full backups, while only taking up the space
14
of one full backup plus differences. When coupled with ssh, it is
15
possible to take snapshots of remote filesystems as well. This
16
document is a tutorial in the installation and configuration of
21
This document is marked up in reStructured Text format.
22
See http://docutils.sf.net/ for more information.
27
======================================================================
29
rsnapshot is a filesystem backup utility based on rsync. Using
30
rsnapshot, it is possible to take snapshots of your filesystems at
31
different points in time. Using hard links, rsnapshot creates the
32
illusion of multiple full backups, while only taking up the space of
33
one full backup plus differences. When coupled with ssh, it is
34
possible to take snapshots of remote filesystems as well.
36
rsnapshot is written in Perl, and depends on rsync. OpenSSH, GNU cp,
37
GNU du, and the BSD logger program are also recommended, but not
38
required. All of these should be present on most Linux
39
systems. rsnapshot is written with the lowest common denominator in
40
mind. It only requires at minimum Perl 5.004 and rsync. As a result of
41
this, it works on pretty much any UNIX-like system you care to throw
42
at it. It has been successfully tested with Perl 5.004 through 5.8.2,
43
on Debian, Redhat, Fedora, Solaris, Mac OS X, FreeBSD, OpenBSD,
46
The latest version of the program and this document can always be
47
found at http://www.rsnapshot.org/.
50
------------------------------------------------------------
52
At a minimum: perl, rsync
54
Optionally: ssh, logger, GNU cp, GNU du
56
Additionally, it will help if you have reasonably good sysadmin skills.
59
------------------------------------------------------------
61
This document, rsnapshot HOWTO, is copyrighted © 2005 by Nathan
62
Rosenquist. You can redistribute it and/or modify it under the terms
63
of the GNU General Public License as published by the Free Software
64
Foundation; either version 2 of the License, or (at your option) any
65
later version. A copy of the license is available at
66
http://www.gnu.org/ copyleft/gpl.html.
69
------------------------------------------------------------
71
No liability for the contents of this document can be accepted. Use
72
the concepts, examples and information at your own risk. There may be
73
errors and inaccuracies, that could be damaging to your
74
system. Proceed with caution, and although this is highly unlikely,
75
the author(s) do not take any responsibility.
77
All copyrights are held by their by their respective owners, unless
78
specifically noted otherwise. Use of a term in this document should
79
not be regarded as affecting the validity of any trademark or service
80
mark. Naming of particular products or brands should not be seen as
84
------------------------------------------------------------
86
Feedback is most certainly welcome for this document. Send your
87
additions, comments and criticisms to the following email address:
91
======================================================================
93
I originally used Mike Rubel's shell scripts to do rsync snapshots a
94
while back. These worked very well, but there were a number of things
95
that I wanted to improve upon. I had to write two shell scripts that
96
were customized for my server. If I wanted to change the number of
97
intervals stored, or the parts of the filesystem that were archived,
98
that meant manually editing these shell scripts. If I wanted to
99
install them on a different server with a different configuration,
100
this meant manually editing the scripts for the new server, and hoping
101
the logic and the sequence of operations was correct. Also, I was
102
doing all the backups locally, on a single machine, on a single hard
103
drive (just to protect from dumb user mistakes like deleting
104
files). Never the less, I continued on with this system for a while,
105
and it did work very well.
107
Several months later, the IDE controller on my web server failed
108
horribly (when I typed /sbin/shutdown, it said the command was not
109
found). I was then faced with what was in the back of my mind all
110
along: I had not been making regular remote backups of my server, and
111
the local backups were of no use to me since the entire drive was
112
corrupted. The reason I had only been making sporadic, partial remote
113
backups is that they weren't automatic and effortless. Of course, this
114
was no one's fault but my own, but I got frustrated enough to write a
115
tool that would make automated remote snapshots so easy that I
116
wouldn't ever have to worry about them again. This goal has long been
117
reached, but work on rsnapshot still continues as people submit
118
patches, request features, and ways are found to improve the program.
121
======================================================================
123
This section will walk you through the installation of rsnapshot, step
124
by step. This is not the only way to do it, but it is a way that works
125
and that is well documented. Feel free to improvise if you know what
128
This guide assumes you are installing rsnapshot 1.2.0 for the first
129
time. If you are upgrading from an earlier version, please read the
130
INSTALL file that comes with the source distribution instead.
132
30 second version (for the impatient)
133
------------------------------------------------------------
137
./configure --sysconfdir=/etc
140
cp /etc/rsnapshot.conf.default /etc/rsnapshot.conf
142
The rest of this section is the long version.
144
Untar the source code package
145
------------------------------------------------------------
149
tar xzvf rsnapshot-1.2.0.tar.gz
151
If you don't have GNU tar, you may have to do this in two steps
154
gunzip rsnapshot-1.2.0.tar.gz
155
tar xvf rsnapshot-1.2.0.tar
157
Change to the source directory
158
------------------------------------------------------------
164
Decide where you want to install
165
------------------------------------------------------------
167
By default, the installation procedure will install all files under
168
/usr/local. For this tutorial, this will be OK except we will install
169
the config file under /etc.
171
We are assuming that rsync, ssh, logger, and du are all in your search
172
path. If this is not the case, you can specify the path to any of
173
these programs using the typical Autoconf
174
--with-program=/path/to/program syntax. For example, if Perl was in
175
/opt/bin/perl and rsync was in /home/me/bin/rsync, you could run
178
./configure --with-perl=/opt/bin/perl --with-rsync=/home/me/bin/rsync
180
Run the configure script
181
------------------------------------------------------------
183
This will poke and prod your system to figure out where the various
184
external programs that rsnapshot depends on live. It also generates
185
the Makefile that we will use to install the program. The configure
186
script accepts arguments that can be used to tell it where to install
187
the program, and also where to find the supporting programs. For this
188
installation, the only non-default option we want is to put the config
189
file in the /etc directory. To do this, run this command at the
192
./configure --sysconfdir=/etc
194
If all goes well, you're ready to install the program. If there was a
195
problem, it should be descriptive. Most likely a problem would be the
196
result of something that was required and not found (like rsync or
197
perl). If this happens, you must figure out where the missing program
198
is located on your system, or install it if necessary. If you know
199
where it is but configure couldn't find it, you can specify the path
200
using the --with-program=/path/to/program options described above.
203
------------------------------------------------------------
205
If you've followed these instructions so far, you will have configured
206
rsnapshot to be installed under /usr/local, with the config file in
207
/etc. Under these circumstances, it will be necessary to become root
208
to install the program. Now is the time to do so. You will, of course,
209
need the root password to do this::
213
This will prompt you for the root password.
215
Now, to install rsnapshot, run the following command::
219
This will install rsnapshot with all the settings you specified in the
220
./configure stage. If all goes well, you will have the following files
223
/usr/local/bin/rsnapshot
224
The rsnapshot program
226
/usr/local/man/man1/rsnapshot.1
229
/etc/rsnapshot.conf.default
230
The example config file
232
If you decide later that you don't want rsnapshot on your system
233
anymore, simply remove the files listed above, or run ``make
234
uninstall`` in the same source directory you installed from. Of
235
course, if you installed with different options, the location of these
236
files may be different.
239
======================================================================
241
Create the config file
242
------------------------------------------------------------
244
In the install process, the config file is not created or
245
installed. However, a working example is provided that you can
246
copy. To copy the example config file into the location rsnapshot will
247
be looking for the real config file::
249
cp /etc/rsnapshot.conf.default /etc/rsnapshot.conf
251
As a general rule, you should avoid modifying
252
/etc/rsnapshot.conf.default, simply because it is a working example
253
that you may wish to refer to later. Also, if you perform an upgrade,
254
the rsnapshot.conf.default file will always be upgraded to the latest
255
version, while your real config file will be safe out of harm's
256
way. Please note that if you run ``make upgrade`` during an upgrade,
257
your rsnapshot.conf may be modified slightly, and the original will
258
then be saved in rsnapshot.conf.backup in the same directory.
260
Where to go for more info
261
------------------------------------------------------------
263
The rsnapshot.conf config file is well commented, and much of it
264
should be fairly self-explanatory. For a full reference of all the
265
various options, please consult the rsnapshot man page. Type::
269
This will give you the complete documentation. However, it assumes
270
that you already know what you're doing to a certain extent. If you
271
just want to get something up and running, this tutorial is a better
272
place to start. If your system can't find the man page, /usr/local/man
273
probably isn't in your $MANPATH environmental variable. This is beyond
274
the scope of this document, but if it isn't working for you, you can
275
always read the newest man page on the rsnapshot web site at
276
http://www.rsnapshot.org/
278
Modifying the config file
279
------------------------------------------------------------
281
In this example, we will be using the /.snapshots/ directory to hold
282
the filesystem snapshots. This is referred to as the "snapshot
283
root". Feel free to put this anywhere you have lots of free disk
284
space. However, the examples in this document assume you have not
285
changed this parameter, so you will have to substitute this in your
286
commands if you put it somewhere else.
288
Also please note that fields are separated by tabs, not spaces. The
289
reason for this is so it's easier to specify file paths with spaces in
293
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
295
If enabled, the cmd_cp parameter should contain the path to the GNU cp
296
program on your filesystem. If you are using Linux, be sure to
297
uncomment this by removing the octothorpe (#) in front of it. If you
298
are using BSD, Solaris, IRIX, or most other UNIX variants, you should
299
leave this commented out.
301
What makes GNU cp so special is that unlike the traditional UNIX
302
cp, it has the ability to make recursive "copies" of directories
305
If you don't have GNU cp, there is a subroutine in rsnapshot that
306
somewhat approximates this functionality (although it won't
307
support more esoteric files such as device nodes, FIFOs, sockets,
308
etc). This gets followed up by another call to rsync, which
309
transfers the remaining special files, if any. In this way,
310
rsnapshot can support all file types on every platform.
312
The rule of thumb is that if you're on a Linux system, leave
313
cmd_cp enabled. If you aren't on a Linux system, leave cmd_cp
314
disabled. There are reports of GNU cp working on BSD and other
315
non-Linux platforms, but there have also been some cases where
316
problems have been encountered. If you enable cmd_cp on a
317
non-Linux platform, please let the mailing list know how it worked
321
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
323
The cmd_rsync parameter must not be commented out, and it must
324
point to a working version of rsync. If it doesn't, the program
325
just will not work at all.
327
Please note that if you are using IRIX, there is another program
328
named rsync that is different than the "real" rsync most people
329
know of. If you're on an IRIX machine, you should double check
333
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
335
If you have ssh installed on your system, you will want to
336
uncomment the cmd_ssh parameter. By enabling ssh, you can take
337
snapshots of any number of remote systems. If you don't have ssh,
338
or plan to only take snapshots of the local filesystem, you may
339
safely leave this commented out.
342
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
344
The cmd_logger parameter specifies the path to the logger
345
program. logger is a command line interface to syslog. See the
346
logger man page for more details. logger should be a standard part
347
of most UNIX-like systems. It appears to have remained unchanged
348
since about 1993, which is good for cross-platform stability. If
349
you comment out this parameter, it will disable syslog support in
350
rsnapshot. It is recommended that you leave this enabled.
353
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
355
The cmd_du parameter specifies the path to the du program. du is a
356
command line tool that reports on disk usage. rsnapshot uses du to
357
generate reports about the actual amount of disk space taken up,
358
which is otherwise difficult to estimate because of all the hard
361
If you comment this out, rsnapshot will try to use the version of
362
du it finds in your path, if possible. The GNU version of du is
363
recommended, since it has the best selection of features, and
364
supports the most options. The BSD version also seems to work,
365
although some versions don't support the -h flag. Solaris du does
366
not work at all, because it doesn't support the -c parameter.
369
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
371
If you have rsync version 2.5.7 or later, you may want to enable
372
this. With link_dest enabled, rsnapshot relies on rsync to create
373
recursive hard links, overriding GNU cp in most, but not all,
374
cases. With link_dest enabled, every single file on your system
375
can be backed up in one pass, on any operating system. To get the
376
most out of rsnapshot on non-Linux platforms, link_dest should be
377
enabled. Be advised, however, that if a remote host is unavailable
378
during a backup, rsnapshot will take an extra step and roll back
379
the files from the previous backup. Using GNU cp, this would not
383
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
385
rsnapshot has no idea how often you want to take
386
snapshots. Everyone's backup scheme may be different. In order to
387
specify how much data to save, you need to tell rsnapshot which
388
"intervals" to keep, and how many of each. An interval, in the
389
context of the rsnapshot config file, is a unit of time
390
measurement. These can actually be named anything (as long as it's
391
alphanumeric, and not a reserved word), but by convention we will
392
call ours hourly and daily. In this example, we want to take a
393
snapshot every four hours, or six times a day (these are the
394
hourly intervals). We also want to keep a second set, which are
395
taken once a day, and stored for a week (or seven days). This
396
happens to be the default, so as you can see the config file
402
It also has some other entries, but you can either ignore them or
403
comment them out for now.
405
Please note that the hourly interval is specified first. This is
406
very important. The first interval line is assumed to be the
407
smallest unit of time, with each additional line getting
408
successively larger. Thus, if you add a yearly interval, it should
409
go at the bottom, and if you add a minutes interval, it should go
410
before hourly. It's also worth noting that the snapshots get
411
"pulled up" from the smallest interval to the largest. In this
412
example, the daily snapshots get pulled from the oldest hourly
413
snapshot, not directly from the main filesystem.
416
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
418
Please note that the destination paths specified here are based on
419
the assumption that the --relative flag is being passed to rsync
420
via the rsync_long_args parameter. If you are installing for the
421
first time, this is the default setting. If you upgraded from a
422
previous version, please read the INSTALL file that came with the
423
source distribution for more information.
425
This is the section where you tell rsnapshot what files you actually
426
want to back up. You put a "backup" parameter first, followed by the
427
full path to the directory or network path you're backing up. The
428
third column is the relative path you want to back up to inside the
429
snapshot root. Let's look at an example::
431
backup /etc/ localhost/
433
In this example, backup tells us it's a backup point. /etc/ is the
434
full path to the directory we want to take snapshots of, and
435
localhost/ is a directory inside the snapshot_root we're going to put
436
them in. Using the word localhost as the destination directory is just
437
a convention. You might also choose to use the server's fully
438
qualified domain name instead of localhost. If you are taking
439
snapshots of several machines on one dedicated backup server, it's a
440
good idea to use their various hostnames as directories to keep track
441
of which files came from which server.
443
In addition to full paths on the local filesystem, you can also backup
444
remote systems using rsync over ssh. If you have ssh installed and
445
enabled (via the cmd_ssh parameter), you can specify a path like::
447
backup root@example.com:/etc/ example.com/
449
This behaves fundamentally the same way, but you must take a few extra
452
- The ssh daemon must be running on example.com
454
- You must have access to the account you specify the remote machine,
455
in this case the root user on example.com.
457
- You must have key-based logins enabled for the root user at
458
example.com, without passphrases. If you wanted to perform backups
459
as another user, you could specify the other user instead of root
460
for the source (i.e. user@domain.com). Please note that allowing
461
remote logins with no passphrase is a security risk that may or may
462
not be acceptable in your situation. Make sure you guard access to
463
the backup server very carefully! For more information on how to set
464
this up, please consult the ssh man page, or a tutorial on using ssh
465
public and private keys. You will find that the key based logins are
466
better in many ways, not just for rsnapshot but for convenience and
467
security in general. `Troy Johnson`__'s excellent tutorial on using
468
nifty ssh features for secure snapshots which, in case his site ever
469
suffers a mishap, is mirrored `here`__ on this site.
471
.. __: http://www.jdmz.net/rsnapshot
472
.. __: http://www.rsnapshot.org/howto/using-rsnapshot-and-ssh.html
474
- This backup occurs over the network, so it may be slower. Since this
475
uses rsync, this is most noticeable during the first
476
backup. Depending on how much your data changes, subsequent backups
477
should go much, much faster since rsync only sends the differences
481
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
483
With this parameter, the second column is the full path to an
484
executable backup script, and the third column is the local path
485
you want to store it in (just like with the "backup"
486
parameter). For example::
488
backup_script /usr/local/bin/backup_pgsql.sh localhost/postgres/
490
In this example, rsnapshot will run the script
491
/usr/local/bin/backup_pgsql.sh in a temp directory, then sync the
492
results into the localhost/postgres/ directory under the snapshot
493
root. You can find the backup_pgsql.sh example script in the utils/
494
directory of the source distribution. Feel free to modify it for your
497
Your backup script simply needs to dump out the contents of whatever
498
it does into it's current working directory. It can create as many
499
files and/or directories as necessary, but it should not put its files
500
in any pre-determined path. The reason for this is that rsnapshot
501
creates a temp directory, changes to that directory, runs the backup
502
script, and then syncs the contents of the temp directory to the local
503
path you specified in the third column. A typical backup script would
504
be one that archives the contents of a database. It might look like
509
/usr/bin/mysqldump -uroot mydatabase > mydatabase.sql
510
/bin/chmod 644 mydatabase.sql
512
There are several example scripts in the utils/ directory of the
513
rsnapshot source distribution to give you more ideas.
515
Make sure the destination path you specify is unique. The backup
516
script will completely overwrite anything in the destination path, so
517
if you tried to specify the same destination twice, you would be left
518
with only the files from the last script. Fortunately, rsnapshot will
519
try to prevent you from doing this when it reads the config file.
521
Please remember that these backup scripts will be invoked as the user
522
running rsnapshot. In our example, this is root. Make sure your backup
523
scripts are owned by root, and not writable by anyone else. If you
524
fail to do this, anyone with write access to these backup scripts will
525
be able to put commands in them that will be run as the root user. If
526
they are malicious, they could take over your server.
528
Testing your config file
529
------------------------------------------------------------
531
When you have made all your changes, you should verify that the config
532
file is syntactically valid, and that all the supporting programs are
533
where you think they are. To do this, run rsnapshot with the
534
configtest argument::
538
If all is well, it should say Syntax OK. If there's a problem, it
539
should tell you exactly what it is. Make sure your config file is
540
using tabs and not spaces, etc.
542
The final step to test your configuration is to run rsnapshot in test
543
mode. This will print out a verbose list of the things it will do,
544
without actually doing them. To do a test run, run this command::
548
This tells rsnapshot to simulate an "hourly" backup. It should print
549
out the commands it will perform when it runs for real. Please note
550
that the test output might be slightly different than the real
551
execution, but only because the test doesn't actually do things that
552
may be checked for later in the program. For example, if the program
553
will create a directory and then later test to see if that directory
554
exists, the test run might claim that it would create the directory
555
twice, since it didn't actually get created during the test. This
556
should be the only type of difference you will see while running a
560
======================================================================
562
Now that you have your config file set up, it's time to set up
563
rsnapshot to be run from cron. As the root user, edit root's crontab
568
You could alternately keep a crontab file that you load in, but the
569
concepts are the same. You want to enter the following information
570
into root's crontab::
572
0 */4 * * * /usr/local/bin/rsnapshot hourly
573
30 23 * * * /usr/local/bin/rsnapshot daily
575
It is usually a good idea to schedule the larger intervals to run a
576
bit before the lower ones. For example, in the crontab above, notice
577
that daily runs 30 minutes before hourly. This helps prevent race
578
conditions where the daily would try to run before the hourly job had
579
finished. This same strategy should be extended so that a weekly entry
580
would run before the daily and so on.
583
======================================================================
585
We have a snapshot root under which all backups are stored. By
586
default, this is the directory /.snapshots/. Within this directory,
587
other directories are created for the various intervals that have been
588
defined. In the beginning it will be empty, but once rsnapshot has
589
been running for a week, it should look something like this::
591
[root@localhost]# ls -l /.snapshots/
592
drwxr-xr-x 7 root root 4096 Dec 28 00:00 daily.0
593
drwxr-xr-x 7 root root 4096 Dec 27 00:00 daily.1
594
drwxr-xr-x 7 root root 4096 Dec 26 00:00 daily.2
595
drwxr-xr-x 7 root root 4096 Dec 25 00:00 daily.3
596
drwxr-xr-x 7 root root 4096 Dec 24 00:00 daily.4
597
drwxr-xr-x 7 root root 4096 Dec 23 00:00 daily.5
598
drwxr-xr-x 7 root root 4096 Dec 22 00:00 daily.6
599
drwxr-xr-x 7 root root 4096 Dec 29 00:00 hourly.0
600
drwxr-xr-x 7 root root 4096 Dec 28 20:00 hourly.1
601
drwxr-xr-x 7 root root 4096 Dec 28 16:00 hourly.2
602
drwxr-xr-x 7 root root 4096 Dec 28 12:00 hourly.3
603
drwxr-xr-x 7 root root 4096 Dec 28 08:00 hourly.4
604
drwxr-xr-x 7 root root 4096 Dec 28 04:00 hourly.5
606
Inside each of these directories is a "full" backup of that point in
607
time. The destination directory paths you specified under the backup
608
and backup_script parameters get stuck directly under these
609
directories. In the example::
611
backup /etc/ localhost/
613
The /etc/ directory will initially get backed up into
614
/.snapshots/hourly.0/localhost/etc/
616
Each subsequent time rsnapshot is run with the hourly command, it will
617
rotate the hourly.X directories, and then "copy" the contents of the
618
hourly.0 directory (using hard links) into hourly.1.
620
When rsnapshot daily is run, it will rotate all the daily.X
621
directories, then copy the contents of hourly.5 into daily.0.
623
hourly.0 will always contain the most recent snapshot, and daily.6
624
will always contain a snapshot from a week ago. Unless the files
625
change between snapshots, the "full" backups are really just multiple
626
hard links to the same files. Thus, if your /etc/passwd file doesn't
627
change in a week, hourly.0/localhost/etc/passwd and
628
daily.6/localhost/etc /passwd will literally be the same exact
629
file. This is how rsnapshot can be so efficient on space. If the file
630
changes at any point, the next backup will unlink the hard link in
631
hourly.0, and replace it with a brand new file. This will now take
632
double the disk space it did before, but it is still considerably less
633
than it would be to have full unique copies of this file 13 times
636
Remember that if you are using different intervals than the ones in
637
this example, the first interval listed is the one that gets updates
638
directly from the main filesystem. All subsequently listed intervals
639
pull from the previous intervals. For example, if you had weekly,
640
monthly, and yearly intervals defined (in that order), the weekly ones
641
would get updated directly from the filesystem, the monthly ones would
642
get updated from weekly, and the yearly ones would get updated from
646
======================================================================
648
When rsnapshot is first run, it will create the snapshot_root
649
directory (/.snapshots/ by default). It assigns this directory the
650
permissions 700, and for good reason. The snapshot root will probably
651
contain files owned by all sorts of users on your system. If any of
652
these files are writeable (and of course some of them will be), the
653
users will still have write access to their files. Thus, if they can
654
see the snapshots directly, they can modify them, and the integrity of
655
the snapshots can not be guaranteed.
657
For example, if a user had write permission to the backups and
658
accidentally ran rm -rf /, they would delete all their files in their
659
home directory and all the files they owned in the backups!
662
------------------------------------------------------------
664
The simplest, but least flexible solution, is to simply deny non-root
665
users access to the snapshot root altogether. The root user will still
666
have access of course, and as with all other aspects of system
667
administration, must be trusted not to go messing with things too
668
much. However, by simply denying access to everyone, the root user
669
will be the only one who can pull backups. This may or may not be
670
desirable, depending on your situation. For a small setup or a
671
single-user machine, this may be all you need.
674
------------------------------------------------------------
676
If users need to be able to pull their own backups, you will need to
677
do a little extra work up front (but probably less work in the long
678
run). The best way to do this seems to be creating a container
679
directory for the snapshot root with 700 permissions, giving the
680
snapshot root directory 755 permissions, and mounting the snapshot
681
root for the users read-only. This can be done over NFS and Samba, to
682
name two possibilities. Let's explore how to do this using NFS on a
685
Set the snapshot_root variable in /etc/rsnapshot.conf equal to
686
/.private/.snapshots/ ::
688
snapshot_root /.private/.snapshots/
690
Create the container directory::
694
Create the real snapshot root::
696
mkdir /.private/.snapshots/
698
Create the read-only snapshot root mount point::
702
Set the proper permissions on these new directories::
704
chmod 0700 /.private/
705
chmod 0755 /.private/.snapshots/
706
chmod 0755 /.snapshots/
708
In /etc/exports, add /.private/.snapshots/ as a read only NFS export::
710
/.private/.snapshots/ 127.0.0.1(ro,no_root_squash)
712
In /etc/fstab, mount /.private/.snapshots/ read-only under
715
localhost:/.private/.snapshots/ /.snapshots/ nfs ro 0 0
717
You should now restart your NFS daemon.
719
Now mount the read-only snapshot root::
723
To test this, go into the /.snapshots/ directory as root. It is set to
724
read-only, so even root shouldn't be able to write to it. As root,
727
touch /.snapshots/testfile
729
This should fail, citing insufficient permissions. This is what you
730
want. It means that your users won't be able to mess with the
733
Now, all your users have to do to recover old files is go into the
734
/.snapshots directory, select the interval they want, and browse
735
through the filesystem until they find the files they are looking
736
for. They can't modify anything in here because NFS will prevent them,
737
but they can copy anything that they had read permission for in the
738
first place. All the regular filesystem permissions are still at
739
work, but the read-only NFS mount prevents any writes from happening.
741
Please note that some NFS configurations may prevent you from
742
accessing files that are owned by root and set to only be readable by
743
root. In this situation, you may wish to pull backups for root from
744
the "real" snapshot root, and let non-privileged users pull from the
748
======================================================================
750
If you followed the instructions in this document, you should now have
751
rsnapshot installed and set up to perform automatic backups of your
752
system. If it's not working, go back and trace your steps back to see
753
if you can isolate the problem.
755
The amount of disk space taken up will be equal to one full backup,
756
plus an additional copy of every file that is changed. There is also a
757
slight disk space overhead with creating multiple hard links, but it's
758
not very much. On my system, adding a second, completely identical 3
759
Gigabyte interval alongside the original one only added about 15
762
You can use the du option to rsnapshot to generate disk usage
763
reports. To see the sum total of all space used, try::
767
If you were storing backups under localhost/home/ and wanted to see
768
how much this subdirectory takes up throughout all your backups, try
771
rsnapshot du localhost/home/
773
The latest version of this document and the rsnapshot program can
774
always be found at http://www.rsnapshot.org/
777
======================================================================
779
Mike Rubel's original shell scripts, upon which this project is based
780
http://www.mikerubel.org/computers/rsync_snapshots/
785
GNU cp and du (coreutils package)
786
http://www.gnu.org/software/coreutils/
789
http://rsync.samba.org/
792
http://www.openssh.org/
795
http://www.rsnapshot.org/