Re: Rsnapshot configuration
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
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
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" 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
Re: Rsnapshot configuration - Data integrity
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
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
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 > # 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 serve
Re: Rsnapshot configuration - Data integrity
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
Re: Rsnapshot configuration - Data integrity
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
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
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&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 ># 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
Re: Rsnapshot configuration
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 # 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,
Re: Rsnapshot configuration
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
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
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
+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
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
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
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