Re: Rsnapshot configuration

[Craig Skinner]

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

Re: Rsnapshot configuration

[Craig Skinner]

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

Re: Rsnapshot configuration

[Branden Harper]

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" <gp...@mailbox.org> 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 b

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/

Re: Rsnapshot configuration - Data integrity

[G]

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

Re: Rsnapshot configuration

[G]

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=144340431520709=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
> # minutehourmdaymonth   wdaycommand
> 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 

Re: Rsnapshot configuration - Data integrity

[Predrag Punosevac]

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=149732026405941=2

Best,
Predrag

Re: Rsnapshot configuration - Data integrity

[Solène Rapenne]

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

Re: Rsnapshot configuration

[Mark Carroll]

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

Re: Rsnapshot configuration

[Edgar Pettijohn]

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  
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=144340431520709=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
># minutehourmdaymonth   wdaycommand
>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
>

Re: Rsnapshot configuration

[Predrag Punosevac]

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=144340431520709=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
# minutehourmdaymonth   wdaycommand
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 

Re: Rsnapshot configuration

[G]

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  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!).
> 
> 

Re: Rsnapshot configuration

[Stuart Henderson]

On 2017-06-13, Paolo Aglialoro  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!).

Re: Rsnapshot configuration

[G]

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"  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
>>
>>

Re: Rsnapshot configuration

[Paolo Aglialoro]

+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"  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
>
>

Re: Rsnapshot configuration

[Stuart Henderson]

On 2017-06-13, G  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.

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

Rsnapshot configuration

[G]

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.
#
loglevel3

# 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-exclud