Rsnapshot configuration

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Rsnapshot configuration

George
Hello!
Im trying to take daily and weekly backups of my system rsnapshot.

I backup

backup / localhost/
backup /altroot/ localhost/
backup /bin/ localhost/
backup /etc/ localhost/
backup /home/ localhost/
backup /root/ localhost/
backup /sbin localhost/
backup /usr/ localhost/


and i exclude

exclude /dev/
exclude /mnt/usb/
exclude /mnt/cdrom/
exclude /tmp/
exclude /var/
exclude /home/.snapshot/

Im not sure if there is anything in var that i should consider backup
like sysmerge or syspatch.

Thanks!


My full /etc/rsnapshot.conf follows


#################################################
# rsnapshot.conf - rsnapshot configuration file #
#################################################
#                                               #
# PLEASE BE AWARE OF THE FOLLOWING RULE:        #
#                                               #
# This file requires tabs between elements      #
#                                               #
#################################################

#######################
# CONFIG FILE VERSION #
#######################

config_version 1.2

###########################
# SNAPSHOT ROOT DIRECTORY #
###########################

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

# If no_create_root is enabled, rsnapshot will not automatically create the
# snapshot_root directory. This is particularly useful if you are backing
# up to removable media, such as a FireWire or USB drive.
#
#no_create_root 1

#################################
# 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 /bin/cp

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

# rsync must be enabled for anything to work. This is the only command that
# must be enabled.
#
cmd_rsync /usr/local/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

# Uncomment this to specify the path to rsnapshot-diff.
#
cmd_rsnapshot_diff /usr/local/bin/rsnapshot-diff

# Specify the path to a script (and any optional arguments) to run right
# before rsnapshot syncs files
#
#cmd_preexec /path/to/preexec/script

# Specify the path to a script (and any optional arguments) to run right
# after rsnapshot syncs files
#
#cmd_postexec /path/to/postexec/script

# Paths to lvcreate, lvremove, mount and umount commands, for use with
# Linux LVMs.
#
#linux_lvm_cmd_lvcreate /path/to/lvcreate
#linux_lvm_cmd_lvremove /path/to/lvremove
#linux_lvm_cmd_mount /sbin/mount
#linux_lvm_cmd_umount /sbin/umount

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

retain daily 3
retain weekly 3

#retain delta 3

############################################
#              GLOBAL OPTIONS              #
# All are optional, with sensible defaults #
############################################

# Verbose level, 1 through 5.
# 1     Quiet           Print fatal errors only
# 2     Default         Print errors and warnings only
# 3     Verbose         Show equivalent shell commands being executed
# 4     Extra Verbose   Show extra verbose information
# 5     Debug mode      Everything
#
verbose 2

# Same as "verbose" above, but controls the amount of data sent to the
# logfile, if one is being used. The default is 3.
#
loglevel 3

# If you enable this, data will be written to the file you specify. The
# amount of data written is controlled by the "loglevel" parameter.
#
#logfile /var/log/rsnapshot

# If enabled, rsnapshot will write a lockfile to prevent two instances
# from running simultaneously (and messing up the snapshot_root).
# If you enable this, make sure the lockfile directory is not world
# writable. Otherwise anyone can prevent the program from running.
#
lockfile /var/run/rsnapshot.pid

# By default, rsnapshot check lockfile, check if PID is running
# and if not, consider lockfile as stale, then start
# Enabling this stop rsnapshot if PID in lockfile is not running
#
#stop_on_stale_lockfile 0

# Default rsync args. All rsync commands have at least these options set.
#
#rsync_short_args -a
#rsync_long_args --delete --numeric-ids --relative --delete-excluded

# ssh has no args passed by default, but you can specify some here.
#
#ssh_args -p 22

# Default arguments for the "du" program (for disk space reporting).
# The GNU version of "du" is preferred. See the man page for more details.
# If your version of "du" doesn't support the -h flag, try -k flag instead.
#
#du_args -csh

# If this is enabled, rsync won't span filesystem partitions within a
# backup point. This essentially passes the -x option to rsync.
# The default is 0 (off).
#
#one_fs 0

# The include and exclude parameters, if enabled, simply get passed directly
# to rsync. If you have multiple include/exclude patterns, put each one on a
# separate line. Please look up the --include and --exclude options in the
# rsync man page for more details on how to specify file name patterns.
#
#include ???
#include ???
#exclude ???


exclude /dev/
exclude /mnt/usb/
exclude /mnt/cdrom/
exclude /tmp/
exclude /var/
exclude /home/.snapshot/




# The include_file and exclude_file parameters, if enabled, simply get
# passed directly to rsync. Please look up the --include-from and
# --exclude-from options in the rsync man page for more details.
#
#include_file /path/to/include/file
#exclude_file /path/to/exclude/file

# If your version of rsync supports --link-dest, consider enabling this.
# This is the best way to support special files (FIFOs, etc) cross-platform.
# The default is 0 (off).
#
link_dest 1

# When sync_first is enabled, it changes the default behaviour of rsnapshot.
# Normally, when rsnapshot is called with its lowest interval
# (i.e.: "rsnapshot alpha"), it will sync files AND rotate the lowest
# intervals. With sync_first enabled, "rsnapshot sync" handles the file
sync,
# and all interval calls simply rotate files. See the man page for more
# details. The default is 0 (off).
#
sync_first 0

# If enabled, rsnapshot will move the oldest directory for each interval
# to [interval_name].delete, then it will remove the lockfile and delete
# that directory just before it exits. The default is 0 (off).
#
#use_lazy_deletes 0

# Number of rsync re-tries. If you experience any network problems or
# network card issues that tend to cause ssh to fail with errors like
# "Corrupted MAC on input", for example, set this to a non-zero value
# to have the rsync operation re-tried.
#
#rsync_numtries 0

# LVM parameters. Used to backup with creating lvm snapshot before backup
# and removing it after. This should ensure consistency of data in some
special
# cases
#
# LVM snapshot(s) size (lvcreate --size option).
#
#linux_lvm_snapshotsize 100M

# Name to be used when creating the LVM logical volume snapshot(s).
#
#linux_lvm_snapshotname rsnapshot

# Path to the LVM Volume Groups.
#
#linux_lvm_vgpath /dev

# Mount point to use to temporarily mount the snapshot(s).
#
#linux_lvm_mountpath /path/to/mount/lvm/snapshot/during/backup

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

# LOCALHOST
#backup /home/ localhost/
#backup /etc/ localhost/
#backup /usr/local/ localhost/
#backup /var/log/rsnapshot localhost/
#backup /etc/passwd localhost/
#backup /home/foo/My Documents/ localhost/
#backup /foo/bar/ localhost/ one_fs=1, rsync_short_args=-urltvpog
#backup_script /usr/local/bin/backup_pgsql.sh localhost/postgres/
# You must set linux_lvm_* parameters below before using lvm snapshots
#backup lvm://vg0/xen-home/ lvm-vg0/xen-home/


backup / localhost/
backup /altroot/ localhost/
backup /bin/ localhost/
backup /etc/ localhost/
backup /home/ localhost/
backup /root/ localhost/
backup /sbin localhost/
backup /usr/ localhost/




# EXAMPLE.COM
#backup_exec /bin/date "+ backup of example.com started at %c"
#backup [hidden email]:/home/ example.com/
+rsync_long_args=--bwlimit=16,exclude=core
#backup [hidden email]:/etc/ example.com/ exclude=mtab,exclude=core
#backup_exec ssh [hidden email] "mysqldump -A > /var/db/dump/mysql.sql"
#backup [hidden email]:/var/db/dump/ example.com/
#backup_exec /bin/date "+ backup of example.com ended at %c"

# CVS.SOURCEFORGE.NET
#backup_script /usr/local/bin/backup_rsnapshot_cvsroot.sh
rsnapshot.cvs.sourceforge.net/

# RSYNC.SAMBA.ORG
#backup rsync://rsync.samba.org/rsyncftp/ rsync.samba.org/rsyncftp/


Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Mark Carroll
On 13 Jun 2017, G. wrote:

> Hello!
> Im trying to take daily and weekly backups of my system rsnapshot.
(snip)
> Im not sure if there is anything in var that i should consider backup
> like sysmerge or syspatch.
(snip)

I have various stuff across different machines that is worth backing up
in var/ like directories for nsd, unbound, www, etc. It all depends what
you're using your machine for thus what you've put in those.

Storage these days is cheap: my usual approach is to back up everything
except stuff that I have hunted down via "du" and suchlike as being
actually rather large and decided I can certainly live without. Better
to back up a bit too much rather than too little. (Note that things like
logs are rather compressible so even "du" may badly overstate them.)

-- Mark

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Stuart Henderson
In reply to this post by George
On 2017-06-13, G <[hidden email]> wrote:

> Hello!
> Im trying to take daily and weekly backups of my system rsnapshot.
>
> I backup
>
> backup / localhost/
> backup /altroot/ localhost/
> backup /bin/ localhost/
> backup /etc/ localhost/
> backup /home/ localhost/
> backup /root/ localhost/
> backup /sbin localhost/
> backup /usr/ localhost/
>
>
> and i exclude
>
> exclude /dev/
> exclude /mnt/usb/
> exclude /mnt/cdrom/
> exclude /tmp/
> exclude /var/
> exclude /home/.snapshot/
>
> Im not sure if there is anything in var that i should consider backup
> like sysmerge or syspatch.

It depends what you're running - you'll have to look at what's in there
and decide for yourself.

Personally I backup /var by default and exclude any specific things
that I don't want.


Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Paolo Aglialoro
In reply to this post by Mark Carroll
+1

Have a full snapshot of your system, otherwise restore will be a nightmare.
Do it with another tool, rsnapshot is mostly useful for data.

Il 13 giu 2017 11:05 AM, "Mark Carroll" <[hidden email]> ha scritto:

> On 13 Jun 2017, G. wrote:
>
> > Hello!
> > Im trying to take daily and weekly backups of my system rsnapshot.
> (snip)
> > Im not sure if there is anything in var that i should consider backup
> > like sysmerge or syspatch.
> (snip)
>
> I have various stuff across different machines that is worth backing up
> in var/ like directories for nsd, unbound, www, etc. It all depends what
> you're using your machine for thus what you've put in those.
>
> Storage these days is cheap: my usual approach is to back up everything
> except stuff that I have hunted down via "du" and suchlike as being
> actually rather large and decided I can certainly live without. Better
> to back up a bit too much rather than too little. (Note that things like
> logs are rather compressible so even "du" may badly overstate them.)
>
> -- Mark
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

George
Most tutorials suggest not to backup tmp and var etc. I decided to
backup the whole var.

What do you suggest? I though rsnapshot was ok?

ps. On linux i was using backintime (which uses rsync) but it seems its
no longer on the packages.

On 06/13/17 19:05, Paolo Aglialoro wrote:

> +1
>
> Have a full snapshot of your system, otherwise restore will be a nightmare.
> Do it with another tool, rsnapshot is mostly useful for data.
>
> Il 13 giu 2017 11:05 AM, "Mark Carroll" <[hidden email]> ha scritto:
>
>> On 13 Jun 2017, G. wrote:
>>
>>> Hello!
>>> Im trying to take daily and weekly backups of my system rsnapshot.
>> (snip)
>>> Im not sure if there is anything in var that i should consider backup
>>> like sysmerge or syspatch.
>> (snip)
>>
>> I have various stuff across different machines that is worth backing up
>> in var/ like directories for nsd, unbound, www, etc. It all depends what
>> you're using your machine for thus what you've put in those.
>>
>> Storage these days is cheap: my usual approach is to back up everything
>> except stuff that I have hunted down via "du" and suchlike as being
>> actually rather large and decided I can certainly live without. Better
>> to back up a bit too much rather than too little. (Note that things like
>> logs are rather compressible so even "du" may badly overstate them.)
>>
>> -- Mark
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Stuart Henderson
In reply to this post by Paolo Aglialoro
On 2017-06-13, Paolo Aglialoro <[hidden email]> wrote:
> Have a full snapshot of your system, otherwise restore will be a nightmare.

Opinions vary. I couldn't care less about backing up things which I can
just reinstall, I just need to know how to get back to that state easily.
There are advantages to a script or config management recipe over a backup
of those things: it also works for building on a new OS version, or the
same one with fresh binaries in case you don't trust the ones you have
for some reason.

> Do it with another tool, rsnapshot is mostly useful for data.

Any working backup that you understand is better than no backup..
Especially if it runs automatically. rsnapshot is one of many things
which will work (and you can't really argue with the ease of restore!).


Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

George
Well as far as /var goes i decided to take a closer look because i am
thinking running aide for system integrity check. So this my rsnapshot.conf

I backup the following files

backup  /       localhost/

(Im not sure if i need anything else other than / for backup )

# backup  /altroot/       localhost/
# backup  /bin/   localhost/
# backup  /etc/   localhost/
# backup  /home/  localhost/
# backup  /root/  localhost/
# backup  /sbin   localhost/
# backup  /usr/   localhost/
# backup  /var/   localhost/


And exclude

exclude /var/authpf
exclude /var/cache
exclude /var/crash
exclude /var/cron
exclude /var/run
exclude /var/sasl
exclude /var/spool
exclude /var/tmp

exclude /dev/
exclude /mnt/usb/
exclude /mnt/cdrom/
exclude /tmp/
exclude /home/.snapshot/


On 06/14/17 00:22, Stuart Henderson wrote:

> On 2017-06-13, Paolo Aglialoro <[hidden email]> wrote:
>> Have a full snapshot of your system, otherwise restore will be a nightmare.
>
> Opinions vary. I couldn't care less about backing up things which I can
> just reinstall, I just need to know how to get back to that state easily.
> There are advantages to a script or config management recipe over a backup
> of those things: it also works for building on a new OS version, or the
> same one with fresh binaries in case you don't trust the ones you have
> for some reason.
>
>> Do it with another tool, rsnapshot is mostly useful for data.
>
> Any working backup that you understand is better than no backup..
> Especially if it runs automatically. rsnapshot is one of many things
> which will work (and you can't really argue with the ease of restore!).
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Predrag Punosevac-2
In reply to this post by George
Somebody hiding behind a pseudonym G wrote:

>
>
> Most tutorials suggest not to backup tmp and var etc. I decided to
> backup the whole var.
>

You were the last person I expected to ask a question on this mailing
list after those "expert advises" you gave people on OpenBSD desktop in
which you insulted 2 dozen port maintainer claiming that their ports are
not up to date.


> What do you suggest? I though rsnapshot was ok?
>

OK for what? The first question is do you really need a backup and what
are you trying to backup? None of us can help you to answer that
question but we can help you to understand different concepts.


In my book there are three different things which people refer to as
backup.

1. Journaling
2. Genuine Backup
3. Archiving


You can think of Journal as a file system level version control system.
HAMMER of DragonFly BSD is the only file system which supports
fine-grained journaling via history command which can be very finly
tuned. ZFS is another file syste/volume manager which supports
journaling via ZFS snapshots. You can read this post of mine

https://marc.info/?l=openbsd-misc&m=144340431520709&w=2

for a very naive comparison of the two.

OpenBSD will hopefully one day have HAMMER 2 but in the mean time your
only option is

sysutils/glastree

or you can become an expert on mtree I suppose.  You could also by a MAC
when Apple finishes their Apple file system.  Journals are useful if you
are dealing with bunch of users who should be really using a version
control systems for whatever they are editing but they are too lazy or
too dumb to do so.


Now comes a genuine backup. A genuine backup is something which you
expect to access on the regular basis with moderate seeking speed.
rsynapshot is an example of a rsync Perl wrapper written for a genuine
backup. Apple time machine is also just a wrapper around rsync. I would
strongly suggest you read the following thread

https://www.reddit.com/user/rsyncnet/?sort=hot

In particular pay attention to the post which starts as

" I have some expertise in this area[1] so I would like to provide some
additional information for future readers of this thread - specifically
on rsync snapshots, rsnapshot, duplicity, attic and borg.

The simplest thing to do is to rsync from one system to another. Very
simple, but the problem is it's just a "dumb mirror" - there is no
history, no versions in the past (snapshots in time) and every day you
do your rsync, you risk clobbering old data that you won't realize you
need until tomorrow. "

Very informative. The only thing I could add is that the guy is not
familiar with HAMMER because otherwise he would notice that we went full
circle. rsync paired with HAMMER is no longer "dumb mirror". If the
target is HAMMER you can do something like

SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
# Order of crontab fields
# minute        hour    mday    month   wday    command
0       7       *       *       *       /usr/local/bin/rsync -aW
--inplace --delete /home/predrag rsync://predrag@192.168.3.2:873/ftp

and you will have full history. That is how I backup my desktop to my
DragonFly file server.

Some other backup tools are dump/restore, Bacula (make sure you backup
the data base because you will not be able to restore), Amanda, HAMMER
mirror stream, ZFS rsnapshot.  The last one which I use at work is
particularly robust in data center settings.

Now that is not the full story of backup. The above is typically related
to backup of data. Sometimes one wants to backup server configuration
files in order to quickly restore the functionality of the server.
OpenBSD way of backing up server configuration files is altroot

https://www.openbsd.org/faq/faq14.html#altroot

OpenBSD comes with a wonderful tool called softraid

http://man.openbsd.org/softraid.4

which can be used to fully encrypt your laptop but also for RAID 1
installation of OpenBSD. Root on RAID 1 gives you a protection but it is
not a backup. Typically I backup such OpenBSD server to an external USB
device via altroot. People have noticed that sometimes it is useful to
backup /var as well. You can use similar approach with /var which I do.
Don't forget to dump your databases before you do /altvar backup.


Finally most home users will really need Archiving. Archiving is
a technique of "permanently" storing data in the case of unlikly loss of
original data. There are many ways to do it. Backup type is time-tested
way to do it. You can use sysutils/duplicity to archive your encrypted
data to Amazon Glacer. Colin Percival will do that for you using the
crypto function scrypt he decovered and this little tool

sysutils/tarsnap

His prices are reasonable. Other formaly inexpensive methoods of
archiving involve burning DVDs and taking them to a remote storage. You
can find the following userful

sysutils/shunt

Anyhow, hopefully the above will give you enough to think about without
overburden you with concepts like incremental, differential, and full
backup.



> ps. On linux i was using backintime (which uses rsync) but it seems its
> no longer on the packages.
>

Probably because OpenBSD crew has very aggressive approach in removing
obsolite, poorly written, unstable, and poor security track record
software from its ports three. You really think that we are incapable of
porting tripwire to OpenBSD? Think again!

Now you can see who actually have obsolite and older version of the
software. It is Linux and I am not talking about Red Hat. I am talking
about Ubuntu.

Best,
Predrag
 


> On 06/13/17 19:05, Paolo Aglialoro wrote:
> > +1
> >
> > Have a full snapshot of your system, otherwise restore will be a
> nightmare.
> > Do it with another tool, rsnapshot is mostly useful for data.
> >
> > Il 13 giu 2017 11:05 AM, "Mark Carroll" <[hidden email]> ha scritto:
> >
> >> On 13 Jun 2017, G. wrote:
> >>
> >>> Hello!
> >>> Im trying to take daily and weekly backups of my system rsnapshot.
> >> (snip)
> >>> Im not sure if there is anything in var that i should consider
> backup
> >>> like sysmerge or syspatch.
> >> (snip)
> >>
> >> I have various stuff across different machines that is worth backing
> up
> >> in var/ like directories for nsd, unbound, www, etc. It all depends
> what
> >> you're using your machine for thus what you've put in those.
> >>
> >> Storage these days is cheap: my usual approach is to back up
> everything
> >> except stuff that I have hunted down via "du" and suchlike as being
> >> actually rather large and decided I can certainly live without.
> Better
> >> to back up a bit too much rather than too little. (Note that things
> like
> >> logs are rather compressible so even "du" may badly overstate them.)
> >>
> >> -- Mark
> >>
> >>

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Edgar Pettijohn III-2
I appreciate this email. I really need to backup my data more/better and this gave​ me a lot to think about.

⁣Sent from BlueMail ​

On Jun 13, 2017, 7:51 PM, at 7:51 PM, Predrag Punosevac <[hidden email]> wrote:

>Somebody hiding behind a pseudonym G wrote:
>
>>
>>
>> Most tutorials suggest not to backup tmp and var etc. I decided to
>> backup the whole var.
>>
>
>You were the last person I expected to ask a question on this mailing
>list after those "expert advises" you gave people on OpenBSD desktop in
>which you insulted 2 dozen port maintainer claiming that their ports
>are
>not up to date.
>
>
>> What do you suggest? I though rsnapshot was ok?
>>
>
>OK for what? The first question is do you really need a backup and what
>are you trying to backup? None of us can help you to answer that
>question but we can help you to understand different concepts.
>
>
>In my book there are three different things which people refer to as
>backup.
>
>1. Journaling
>2. Genuine Backup
>3. Archiving
>
>
>You can think of Journal as a file system level version control system.
>HAMMER of DragonFly BSD is the only file system which supports
>fine-grained journaling via history command which can be very finly
>tuned. ZFS is another file syste/volume manager which supports
>journaling via ZFS snapshots. You can read this post of mine
>
>https://marc.info/?l=openbsd-misc&m=144340431520709&w=2
>
>for a very naive comparison of the two.
>
>OpenBSD will hopefully one day have HAMMER 2 but in the mean time your
>only option is
>
>sysutils/glastree
>
>or you can become an expert on mtree I suppose.  You could also by a
>MAC
>when Apple finishes their Apple file system.  Journals are useful if
>you
>are dealing with bunch of users who should be really using a version
>control systems for whatever they are editing but they are too lazy or
>too dumb to do so.
>
>
>Now comes a genuine backup. A genuine backup is something which you
>expect to access on the regular basis with moderate seeking speed.
>rsynapshot is an example of a rsync Perl wrapper written for a genuine
>backup. Apple time machine is also just a wrapper around rsync. I would
>strongly suggest you read the following thread
>
>https://www.reddit.com/user/rsyncnet/?sort=hot
>
>In particular pay attention to the post which starts as
>
>" I have some expertise in this area[1] so I would like to provide some
>additional information for future readers of this thread - specifically
>on rsync snapshots, rsnapshot, duplicity, attic and borg.
>
>The simplest thing to do is to rsync from one system to another. Very
>simple, but the problem is it's just a "dumb mirror" - there is no
>history, no versions in the past (snapshots in time) and every day you
>do your rsync, you risk clobbering old data that you won't realize you
>need until tomorrow. "
>
>Very informative. The only thing I could add is that the guy is not
>familiar with HAMMER because otherwise he would notice that we went
>full
>circle. rsync paired with HAMMER is no longer "dumb mirror". If the
>target is HAMMER you can do something like
>
>SHELL=/bin/sh
>PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
># Order of crontab fields
># minute        hour    mday    month   wday    command
>0       7       *       *       *       /usr/local/bin/rsync -aW
>--inplace --delete /home/predrag rsync://predrag@192.168.3.2:873/ftp
>
>and you will have full history. That is how I backup my desktop to my
>DragonFly file server.
>
>Some other backup tools are dump/restore, Bacula (make sure you backup
>the data base because you will not be able to restore), Amanda, HAMMER
>mirror stream, ZFS rsnapshot.  The last one which I use at work is
>particularly robust in data center settings.
>
>Now that is not the full story of backup. The above is typically
>related
>to backup of data. Sometimes one wants to backup server configuration
>files in order to quickly restore the functionality of the server.
>OpenBSD way of backing up server configuration files is altroot
>
>https://www.openbsd.org/faq/faq14.html#altroot
>
>OpenBSD comes with a wonderful tool called softraid
>
>http://man.openbsd.org/softraid.4
>
>which can be used to fully encrypt your laptop but also for RAID 1
>installation of OpenBSD. Root on RAID 1 gives you a protection but it
>is
>not a backup. Typically I backup such OpenBSD server to an external USB
>device via altroot. People have noticed that sometimes it is useful to
>backup /var as well. You can use similar approach with /var which I do.
>Don't forget to dump your databases before you do /altvar backup.
>
>
>Finally most home users will really need Archiving. Archiving is
>a technique of "permanently" storing data in the case of unlikly loss
>of
>original data. There are many ways to do it. Backup type is time-tested
>way to do it. You can use sysutils/duplicity to archive your encrypted
>data to Amazon Glacer. Colin Percival will do that for you using the
>crypto function scrypt he decovered and this little tool
>
>sysutils/tarsnap
>
>His prices are reasonable. Other formaly inexpensive methoods of
>archiving involve burning DVDs and taking them to a remote storage. You
>can find the following userful
>
>sysutils/shunt
>
>Anyhow, hopefully the above will give you enough to think about without
>overburden you with concepts like incremental, differential, and full
>backup.
>
>
>
>> ps. On linux i was using backintime (which uses rsync) but it seems
>its
>> no longer on the packages.
>>
>
>Probably because OpenBSD crew has very aggressive approach in removing
>obsolite, poorly written, unstable, and poor security track record
>software from its ports three. You really think that we are incapable
>of
>porting tripwire to OpenBSD? Think again!
>
>Now you can see who actually have obsolite and older version of the
>software. It is Linux and I am not talking about Red Hat. I am talking
>about Ubuntu.
>
>Best,
>Predrag
>
>
>
>> On 06/13/17 19:05, Paolo Aglialoro wrote:
>> > +1
>> >
>> > Have a full snapshot of your system, otherwise restore will be a
>> nightmare.
>> > Do it with another tool, rsnapshot is mostly useful for data.
>> >
>> > Il 13 giu 2017 11:05 AM, "Mark Carroll" <[hidden email]> ha scritto:
>> >
>> >> On 13 Jun 2017, G. wrote:
>> >>
>> >>> Hello!
>> >>> Im trying to take daily and weekly backups of my system
>rsnapshot.
>> >> (snip)
>> >>> Im not sure if there is anything in var that i should consider
>> backup
>> >>> like sysmerge or syspatch.
>> >> (snip)
>> >>
>> >> I have various stuff across different machines that is worth
>backing
>> up
>> >> in var/ like directories for nsd, unbound, www, etc. It all
>depends
>> what
>> >> you're using your machine for thus what you've put in those.
>> >>
>> >> Storage these days is cheap: my usual approach is to back up
>> everything
>> >> except stuff that I have hunted down via "du" and suchlike as
>being
>> >> actually rather large and decided I can certainly live without.
>> Better
>> >> to back up a bit too much rather than too little. (Note that
>things
>> like
>> >> logs are rather compressible so even "du" may badly overstate
>them.)
>> >>
>> >> -- Mark
>> >>
>> >>
Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Mark Carroll
In reply to this post by Predrag Punosevac-2
On 13 Jun 2017, Predrag Punosevac wrote:
(snip)
> The simplest thing to do is to rsync from one system to another. Very
> simple, but the problem is it's just a "dumb mirror" - there is no
> history, no versions in the past (snapshots in time) and every day you
> do your rsync, you risk clobbering old data that you won't realize you
> need until tomorrow. "

It's worth noting that backing up to a large removable target volume
allows use of rsync's --link-dest option making it easier to efficiently
keep multiple snapshots if one doesn't often rearrange one's filesystem.

(snip)
> His prices are reasonable. Other formaly inexpensive methoods of
> archiving involve burning DVDs and taking them to a remote storage.
(snip)

These days TB-scale external SSDs a make for a handy way to then get
the data off-site: for many typical situations they allow storage of
multiple backups for which we didn't have to be too picky about what
goes onto them. (Those with enterprise-scale money and needs are
obviously in a rather different category.)

One size doesn't fit all, but rsync --link-dest to high-capacity
external drives is such a handy option these days for easily browsed
past backups that I figured it was worth mentioning explicitly on top
of your excellent general article.

-- Mark

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration - Data integrity

Solene Rapenne
In reply to this post by George
Je 2017-06-14 01:47, G skribis:
> Well as far as /var goes i decided to take a closer look because i am
> thinking running aide for system integrity check. So this my
> rsnapshot.conf
>

Recently I've been investigating software for integrity check, you have
choice :

- sysutils/bitrot
- a daily mtree as it's done for /etc ; see security(8)
- archivers/par2cmdline (which can also repair files)
- sysutils/aide

I wouldn't really recommend AIDE. bitrot is a lot easier to use.

I wrote an article about data integrity software :

http : https://dataswamp.org/~solene/article-integrity.html

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration - Data integrity

Predrag Punosevac-2
Solene Rapenne wrote:

>
> Je 2017-06-14 01:47, G skribis:
> > Well as far as /var goes i decided to take a closer look because i am
> > thinking running aide for system integrity check. So this my
> > rsnapshot.conf
> >
>
> Recently I've been investigating software for integrity check, you have
> choice :
>
> - sysutils/bitrot
> - a daily mtree as it's done for /etc ; see security(8)
> - archivers/par2cmdline (which can also repair files)
> - sysutils/aide
>
> I wouldn't really recommend AIDE. bitrot is a lot easier to use.
>
> I wrote an article about data integrity software :
>
> http : https://dataswamp.org/~solene/article-integrity.html

Thank you so much for bringing this important topic back to the
attention of the list subscribers and for writing that wonderful
article.  Note that OpenBSD keeps the last two versions of all important
system files from /etc and /var in

/var/backups

(one more reason for backing up /var). The greatest benefit of porting
an advanced file system like HAMMER 2 (if Matt ever finishes his work)
is in data integrity area (assuming that HAMMER 2 will support
copy-on-write, check-sums, and consistency check like HAMMER 1).
Self-healing which unlike on ZFS is not automatically done on HAMMER 1
would be nice to have as well.

Speaking as somebody who spends to much time for my own good working
with big data guys I see another security benefit of "data integrity"
checks. Namely a good data integrity/anomaly detection could go a long
way as a host-based intrusion detection monitoring/protection. No other
OS is so perfectly position as OpenBSD to take advantage of those
advanced file systems features, having already things like pledge, W^X,
and possibly soon KARL running by default.

https://marc.info/?l=openbsd-tech&m=149732026405941&w=2

Best,
Predrag

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

George
In reply to this post by Predrag Punosevac-2
First of all thanks for your extended and structured replay. There are
some options I haven't considered although I searched various options.

For now all I want is a local backup for my home workstation until I set
a NFS or something similar on my home. That would be a better option.
The reason for the backup is that I want to be able to return fast to a
previous working system in case I mess my system.

PS. As far as my answer goes.(OpenBSD as Desktop) I just tried to be
helpful. I should say that I don't feel that I insult someone with my
answer. As far as I can understand it contribution to the ports is on
voluntary base. Saying that some packages on port are not up to date is
a reality and it isn't anybody s fault.


On 06/14/17 03:50, Predrag Punosevac wrote:

> Somebody hiding behind a pseudonym G wrote:
>
>>
>>
>> Most tutorials suggest not to backup tmp and var etc. I decided to
>> backup the whole var.
>>
>
> You were the last person I expected to ask a question on this mailing
> list after those "expert advises" you gave people on OpenBSD desktop in
> which you insulted 2 dozen port maintainer claiming that their ports are
> not up to date.
>
>
>> What do you suggest? I though rsnapshot was ok?
>>
>
> OK for what? The first question is do you really need a backup and what
> are you trying to backup? None of us can help you to answer that
> question but we can help you to understand different concepts.
>
>
> In my book there are three different things which people refer to as
> backup.
>
> 1. Journaling
> 2. Genuine Backup
> 3. Archiving
>
>
> You can think of Journal as a file system level version control system.
> HAMMER of DragonFly BSD is the only file system which supports
> fine-grained journaling via history command which can be very finly
> tuned. ZFS is another file syste/volume manager which supports
> journaling via ZFS snapshots. You can read this post of mine
>
> https://marc.info/?l=openbsd-misc&m=144340431520709&w=2
>
> for a very naive comparison of the two.
>
> OpenBSD will hopefully one day have HAMMER 2 but in the mean time your
> only option is
>
> sysutils/glastree
>
> or you can become an expert on mtree I suppose.  You could also by a MAC
> when Apple finishes their Apple file system.  Journals are useful if you
> are dealing with bunch of users who should be really using a version
> control systems for whatever they are editing but they are too lazy or
> too dumb to do so.
>
>
> Now comes a genuine backup. A genuine backup is something which you
> expect to access on the regular basis with moderate seeking speed.
> rsynapshot is an example of a rsync Perl wrapper written for a genuine
> backup. Apple time machine is also just a wrapper around rsync. I would
> strongly suggest you read the following thread
>
> https://www.reddit.com/user/rsyncnet/?sort=hot
>
> In particular pay attention to the post which starts as
>
> " I have some expertise in this area[1] so I would like to provide some
> additional information for future readers of this thread - specifically
> on rsync snapshots, rsnapshot, duplicity, attic and borg.
>
> The simplest thing to do is to rsync from one system to another. Very
> simple, but the problem is it's just a "dumb mirror" - there is no
> history, no versions in the past (snapshots in time) and every day you
> do your rsync, you risk clobbering old data that you won't realize you
> need until tomorrow. "
>
> Very informative. The only thing I could add is that the guy is not
> familiar with HAMMER because otherwise he would notice that we went full
> circle. rsync paired with HAMMER is no longer "dumb mirror". If the
> target is HAMMER you can do something like
>
> SHELL=/bin/sh
> PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
> # Order of crontab fields
> # minute        hour    mday    month   wday    command
> 0       7       *       *       *       /usr/local/bin/rsync -aW
> --inplace --delete /home/predrag rsync://predrag@192.168.3.2:873/ftp
>
> and you will have full history. That is how I backup my desktop to my
> DragonFly file server.
>
> Some other backup tools are dump/restore, Bacula (make sure you backup
> the data base because you will not be able to restore), Amanda, HAMMER
> mirror stream, ZFS rsnapshot.  The last one which I use at work is
> particularly robust in data center settings.
>
> Now that is not the full story of backup. The above is typically related
> to backup of data. Sometimes one wants to backup server configuration
> files in order to quickly restore the functionality of the server.
> OpenBSD way of backing up server configuration files is altroot
>
> https://www.openbsd.org/faq/faq14.html#altroot
>
> OpenBSD comes with a wonderful tool called softraid
>
> http://man.openbsd.org/softraid.4
>
> which can be used to fully encrypt your laptop but also for RAID 1
> installation of OpenBSD. Root on RAID 1 gives you a protection but it is
> not a backup. Typically I backup such OpenBSD server to an external USB
> device via altroot. People have noticed that sometimes it is useful to
> backup /var as well. You can use similar approach with /var which I do.
> Don't forget to dump your databases before you do /altvar backup.
>
>
> Finally most home users will really need Archiving. Archiving is
> a technique of "permanently" storing data in the case of unlikly loss of
> original data. There are many ways to do it. Backup type is time-tested
> way to do it. You can use sysutils/duplicity to archive your encrypted
> data to Amazon Glacer. Colin Percival will do that for you using the
> crypto function scrypt he decovered and this little tool
>
> sysutils/tarsnap
>
> His prices are reasonable. Other formaly inexpensive methoods of
> archiving involve burning DVDs and taking them to a remote storage. You
> can find the following userful
>
> sysutils/shunt
>
> Anyhow, hopefully the above will give you enough to think about without
> overburden you with concepts like incremental, differential, and full
> backup.
>
>
>
>> ps. On linux i was using backintime (which uses rsync) but it seems its
>> no longer on the packages.
>>
>
> Probably because OpenBSD crew has very aggressive approach in removing
> obsolite, poorly written, unstable, and poor security track record
> software from its ports three. You really think that we are incapable of
> porting tripwire to OpenBSD? Think again!
>
> Now you can see who actually have obsolite and older version of the
> software. It is Linux and I am not talking about Red Hat. I am talking
> about Ubuntu.
>
> Best,
> Predrag
>  
>
>
>> On 06/13/17 19:05, Paolo Aglialoro wrote:
>>> +1
>>>
>>> Have a full snapshot of your system, otherwise restore will be a
>> nightmare.
>>> Do it with another tool, rsnapshot is mostly useful for data.
>>>
>>> Il 13 giu 2017 11:05 AM, "Mark Carroll" <[hidden email]> ha scritto:
>>>
>>>> On 13 Jun 2017, G. wrote:
>>>>
>>>>> Hello!
>>>>> Im trying to take daily and weekly backups of my system rsnapshot.
>>>> (snip)
>>>>> Im not sure if there is anything in var that i should consider
>> backup
>>>>> like sysmerge or syspatch.
>>>> (snip)
>>>>
>>>> I have various stuff across different machines that is worth backing
>> up
>>>> in var/ like directories for nsd, unbound, www, etc. It all depends
>> what
>>>> you're using your machine for thus what you've put in those.
>>>>
>>>> Storage these days is cheap: my usual approach is to back up
>> everything
>>>> except stuff that I have hunted down via "du" and suchlike as being
>>>> actually rather large and decided I can certainly live without.
>> Better
>>>> to back up a bit too much rather than too little. (Note that things
>> like
>>>> logs are rather compressible so even "du" may badly overstate them.)
>>>>
>>>> -- Mark
>>>>
>>>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration - Data integrity

George
In reply to this post by Solene Rapenne
I didn't want to use aide for data integrity. Just wanted/want to
familiarize my self with various intrusion detection tools.
Thanks for your answer.
I will give it a try when I set up a NFS on my home.

Thanks again for your answer.

On 06/14/17 10:32, Solène Rapenne wrote:

> Je 2017-06-14 01:47, G skribis:
>> Well as far as /var goes i decided to take a closer look because i am
>> thinking running aide for system integrity check. So this my
>> rsnapshot.conf
>>
>
> Recently I've been investigating software for integrity check, you have
> choice :
>
> - sysutils/bitrot
> - a daily mtree as it's done for /etc ; see security(8)
> - archivers/par2cmdline (which can also repair files)
> - sysutils/aide
>
> I wouldn't really recommend AIDE. bitrot is a lot easier to use.
>
> I wrote an article about data integrity software :
>
> http : https://dataswamp.org/~solene/article-integrity.html

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration - Data integrity

viq .
On 17-06-14 21:43:58, G wrote:
> I didn't want to use aide for data integrity. Just wanted/want to
> familiarize my self with various intrusion detection tools.

In that case also have a look at https://ossec.github.io/
and http://www.la-samhna.de/samhain/

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

bharper
In reply to this post by George
I use the built in dump/restore tools for ufs/ffs.  I have never been lead
astray there.  You can script around it to make sure disks are there (or to
push across the network).

On Jun 13, 2017 3:42 AM, "G" <[hidden email]> wrote:

> Hello!
> Im trying to take daily and weekly backups of my system rsnapshot.
>
> I backup
>
> backup  /       localhost/
> backup  /altroot/       localhost/
> backup  /bin/   localhost/
> backup  /etc/   localhost/
> backup  /home/  localhost/
> backup  /root/  localhost/
> backup  /sbin   localhost/
> backup  /usr/   localhost/
>
>
> and i exclude
>
> exclude /dev/
> exclude /mnt/usb/
> exclude /mnt/cdrom/
> exclude /tmp/
> exclude /var/
> exclude /home/.snapshot/
>
> Im not sure if there is anything in var that i should consider backup
> like sysmerge or syspatch.
>
> Thanks!
>
>
> My full /etc/rsnapshot.conf follows
>
>
> #################################################
> # rsnapshot.conf - rsnapshot configuration file #
> #################################################
> #                                               #
> # PLEASE BE AWARE OF THE FOLLOWING RULE:        #
> #                                               #
> # This file requires tabs between elements      #
> #                                               #
> #################################################
>
> #######################
> # CONFIG FILE VERSION #
> #######################
>
> config_version  1.2
>
> ###########################
> # SNAPSHOT ROOT DIRECTORY #
> ###########################
>
> # All snapshots will be stored under this root directory.
> #
> snapshot_root   /home/.snapshots/
>
> # If no_create_root is enabled, rsnapshot will not automatically create the
> # snapshot_root directory. This is particularly useful if you are backing
> # up to removable media, such as a FireWire or USB drive.
> #
> #no_create_root 1
>
> #################################
> # 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          /bin/cp
>
> # uncomment this to use the rm program instead of the built-in perl
> routine.
> #
> cmd_rm          /bin/rm
>
> # rsync must be enabled for anything to work. This is the only command that
> # must be enabled.
> #
> cmd_rsync       /usr/local/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
>
> # Uncomment this to specify the path to rsnapshot-diff.
> #
> cmd_rsnapshot_diff      /usr/local/bin/rsnapshot-diff
>
> # Specify the path to a script (and any optional arguments) to run right
> # before rsnapshot syncs files
> #
> #cmd_preexec    /path/to/preexec/script
>
> # Specify the path to a script (and any optional arguments) to run right
> # after rsnapshot syncs files
> #
> #cmd_postexec   /path/to/postexec/script
>
> # Paths to lvcreate, lvremove, mount and umount commands, for use with
> # Linux LVMs.
> #
> #linux_lvm_cmd_lvcreate /path/to/lvcreate
> #linux_lvm_cmd_lvremove /path/to/lvremove
> #linux_lvm_cmd_mount    /sbin/mount
> #linux_lvm_cmd_umount   /sbin/umount
>
> #########################################
> #     BACKUP LEVELS / INTERVALS         #
> # Must be unique and in ascending order #
> # e.g. alpha, beta, gamma, etc.         #
> #########################################
>
> retain  daily   3
> retain  weekly  3
>
> #retain delta   3
>
> ############################################
> #              GLOBAL OPTIONS              #
> # All are optional, with sensible defaults #
> ############################################
>
> # Verbose level, 1 through 5.
> # 1     Quiet           Print fatal errors only
> # 2     Default         Print errors and warnings only
> # 3     Verbose         Show equivalent shell commands being executed
> # 4     Extra Verbose   Show extra verbose information
> # 5     Debug mode      Everything
> #
> verbose         2
>
> # Same as "verbose" above, but controls the amount of data sent to the
> # logfile, if one is being used. The default is 3.
> #
> loglevel        3
>
> # If you enable this, data will be written to the file you specify. The
> # amount of data written is controlled by the "loglevel" parameter.
> #
> #logfile        /var/log/rsnapshot
>
> # If enabled, rsnapshot will write a lockfile to prevent two instances
> # from running simultaneously (and messing up the snapshot_root).
> # If you enable this, make sure the lockfile directory is not world
> # writable. Otherwise anyone can prevent the program from running.
> #
> lockfile        /var/run/rsnapshot.pid
>
> # By default, rsnapshot check lockfile, check if PID is running
> # and if not, consider lockfile as stale, then start
> # Enabling this stop rsnapshot if PID in lockfile is not running
> #
> #stop_on_stale_lockfile         0
>
> # Default rsync args. All rsync commands have at least these options set.
> #
> #rsync_short_args       -a
> #rsync_long_args        --delete --numeric-ids --relative --delete-excluded
>
> # ssh has no args passed by default, but you can specify some here.
> #
> #ssh_args       -p 22
>
> # Default arguments for the "du" program (for disk space reporting).
> # The GNU version of "du" is preferred. See the man page for more details.
> # If your version of "du" doesn't support the -h flag, try -k flag instead.
> #
> #du_args        -csh
>
> # If this is enabled, rsync won't span filesystem partitions within a
> # backup point. This essentially passes the -x option to rsync.
> # The default is 0 (off).
> #
> #one_fs         0
>
> # The include and exclude parameters, if enabled, simply get passed
> directly
> # to rsync. If you have multiple include/exclude patterns, put each one on
> a
> # separate line. Please look up the --include and --exclude options in the
> # rsync man page for more details on how to specify file name patterns.
> #
> #include        ???
> #include        ???
> #exclude        ???
>
>
> exclude /dev/
> exclude /mnt/usb/
> exclude /mnt/cdrom/
> exclude /tmp/
> exclude /var/
> exclude /home/.snapshot/
>
>
>
>
> # The include_file and exclude_file parameters, if enabled, simply get
> # passed directly to rsync. Please look up the --include-from and
> # --exclude-from options in the rsync man page for more details.
> #
> #include_file   /path/to/include/file
> #exclude_file   /path/to/exclude/file
>
> # If your version of rsync supports --link-dest, consider enabling this.
> # This is the best way to support special files (FIFOs, etc)
> cross-platform.
> # The default is 0 (off).
> #
> link_dest       1
>
> # When sync_first is enabled, it changes the default behaviour of
> rsnapshot.
> # Normally, when rsnapshot is called with its lowest interval
> # (i.e.: "rsnapshot alpha"), it will sync files AND rotate the lowest
> # intervals. With sync_first enabled, "rsnapshot sync" handles the file
> sync,
> # and all interval calls simply rotate files. See the man page for more
> # details. The default is 0 (off).
> #
> sync_first      0
>
> # If enabled, rsnapshot will move the oldest directory for each interval
> # to [interval_name].delete, then it will remove the lockfile and delete
> # that directory just before it exits. The default is 0 (off).
> #
> #use_lazy_deletes       0
>
> # Number of rsync re-tries. If you experience any network problems or
> # network card issues that tend to cause ssh to fail with errors like
> # "Corrupted MAC on input", for example, set this to a non-zero value
> # to have the rsync operation re-tried.
> #
> #rsync_numtries 0
>
> # LVM parameters. Used to backup with creating lvm snapshot before backup
> # and removing it after. This should ensure consistency of data in some
> special
> # cases
> #
> # LVM snapshot(s) size (lvcreate --size option).
> #
> #linux_lvm_snapshotsize 100M
>
> # Name to be used when creating the LVM logical volume snapshot(s).
> #
> #linux_lvm_snapshotname rsnapshot
>
> # Path to the LVM Volume Groups.
> #
> #linux_lvm_vgpath       /dev
>
> # Mount point to use to temporarily mount the snapshot(s).
> #
> #linux_lvm_mountpath    /path/to/mount/lvm/snapshot/during/backup
>
> ###############################
> ### BACKUP POINTS / SCRIPTS ###
> ###############################
>
> # LOCALHOST
> #backup /home/          localhost/
> #backup /etc/           localhost/
> #backup /usr/local/     localhost/
> #backup /var/log/rsnapshot              localhost/
> #backup /etc/passwd     localhost/
> #backup /home/foo/My Documents/         localhost/
> #backup /foo/bar/       localhost/      one_fs=1,
> rsync_short_args=-urltvpog
> #backup_script  /usr/local/bin/backup_pgsql.sh  localhost/postgres/
> # You must set linux_lvm_* parameters below before using lvm snapshots
> #backup lvm://vg0/xen-home/     lvm-vg0/xen-home/
>
>
> backup  /       localhost/
> backup  /altroot/       localhost/
> backup  /bin/   localhost/
> backup  /etc/   localhost/
> backup  /home/  localhost/
> backup  /root/  localhost/
> backup  /sbin   localhost/
> backup  /usr/   localhost/
>
>
>
>
> # EXAMPLE.COM
> #backup_exec    /bin/date "+ backup of example.com started at %c"
> #backup [hidden email]:/home/ example.com/
> +rsync_long_args=--bwlimit=16,exclude=core
> #backup [hidden email]:/etc/  example.com/    exclude=mtab,exclude=core
> #backup_exec    ssh [hidden email] "mysqldump -A >
> /var/db/dump/mysql.sql"
> #backup [hidden email]:/var/db/dump/  example.com/
> #backup_exec    /bin/date "+ backup of example.com ended at %c"
>
> # CVS.SOURCEFORGE.NET
> #backup_script  /usr/local/bin/backup_rsnapshot_cvsroot.sh
> rsnapshot.cvs.sourceforge.net/
>
> # RSYNC.SAMBA.ORG
> #backup rsync://rsync.samba.org/rsyncftp/       rsync.samba.org/rsyncftp/
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Craig Skinner-3
On Fri, 16 Jun 2017 10:21:10 -0500 Branden Harper wrote:
> I use the built in dump/restore tools for ufs/ffs.

Same here Brandon. These tools are written and audited by skilled
OpenBSD developers, _for_ OpenBSD's file system. Sweet.

> I have never been lead astray there.

They work very well + in single user mode /var & /usr can be unmounted.

Never hit the rsync "too many files" problems either.

> You can script around it to make sure disks are there (or to push
> across the network).

My scripts do Tower of Hanoi incremental backups nightly, encrypting
the raw dumps, then scp duplicate the encrypted dumps off site too.

http://en.wikipedia.org/wiki/Backup_rotation_scheme#Tower_of_Hanoi

All done with standard quality tools included in base.

Nice,
--
Craig Skinner | http://linkd.in/yGqkv7

Reply | Threaded
Open this post in threaded view
|

Re: Rsnapshot configuration

Craig Skinner-3
On Sat, 17 Jun 2017 11:05:41 Craig Skinner wrote:
> On Fri, 16 Jun 2017 10:21:10 -0500 Branden Harper wrote:
> > I use the built in dump/restore tools for ufs/ffs.  
>
> Same here Brandon. These tools are written and audited by skilled
> OpenBSD developers, _for_ OpenBSD's file system. Sweet.

dump(8) also honours the file system's nodump flag (configurable level),
so no need for any exclude complicated lists.

chflags(1) can set this flag recursively, which is very useful on /var/

Very simple, reliable & quality audited code, built beautifully in base.

Ace,
--
Craig Skinner | http://linkd.in/yGqkv7