Welcome! » Log In » Create A New Profile

rsnapshot is flawed.

Posted by Anonymous 
rsnapshot is flawed.
April 04, 2012 04:12AM
Hi.

Sorry for the rudeness in the summary.
rsnapshot is offcourse very usable, and it handles backup jobs for heaps
of people without problems!

I've been looking for a sane backup-tool to do my incremental backups to
a remote machine...

rsnapshot seemed perfect at first sight:
- rsync based
- daily, monthly, etc backups, with automatic rotation!
- hard linking to save space
- instant browsability of backups
- simple config files (I used the command line option to specify a
custom config file, and include_conf in that file so I could specify
different snapshot_root's for each "backup job")
- widely used, proven to work
- good documentation

But...

The way rsnapshot only syncs to the top-most interval/retain config
directory (e.g "daily"), while all the subsequent snapshot jobs (e.g.
"weekly"/"monthly") depends on the the first one in this list, is really
flawed, confusing and error prone in my opinion.

When running "rsnapshot weekly" when having "retain daily 3" at the top
in the config file, you'll get a weekly backup _only_ if daily.0 exists,
and regardless of when daily.0 was created.

If you no longer need daily backups, and decide to comment out
"rsnapshot daily" in cron, while forgetting to comment out "retain daily
NUM" in the config file, then your backup plan is completely borked!

In addition to this, it also seems like it is very important to run the
cron daily/weekly/monthly jobs in the correct order, and with a
(uncertain) delay between each of them, in order for rsnapshot to work
correctly.

I also dislike the way rsnapshot forces you to seperate arguments with
<TAB> in the config file.
Especially because my editor (vim) expands all tabs to 4 spaces. It
would be much better if rsnapshot required quotes around the config
arguments that contains spaces.

I hope I'm not offending anyone, but large portions of the rsnapshot
code also seems old and outdated (atleast at first sight), and would
probably benefit alot from some simple refactoring, cleanup and
abstraction. I'm blaming this mostly on the age of the Perl code
(2003-2005).

And..
Why should you have to specify "retain daily 3", "retain weekly 4", and
so on, in the config when you'll have to create seperate cron-jobs for
all of these anyway?
It doesn't make sense?

It would be better to specify this on the command line. Something like:
rsnapshot daily 3
rsnapshot weekly 4

Or even (the way I'd like it):
rsnapshot -c htpc.conf -s daily -k 3
rsnapshot -c htpc.conf -s weekly -k 4
rsnapshot -c laptop.conf -s daily -k 30
rsnapshot -c laptop.conf -s weekly -k 6

-c (above) would obviously be the config file to use (containing stuff
like $SNAPSHOT_ROOT, $SNAPSHOT_NAME, $DESTINATION)
-s would specify the $SNAPSHOT_SUBNAME (e.g daily/weekly/monthly)
-k would specify number of files to keep for
$SNAPSHOT_NAME.$SNAPSHOT_SUBNAME* in $SNAPSHOT_ROOT

I created a bash script which serves like a proof of concept for what
I'd like to do.
It doesn't support different config files, and it doesn't parse command
line arguments like in the example above, but it has (imo) a much better
algorithm for dealing with incremental backups!

To create some dirs and files for testing my script, run:
mkdir -p ~/rsnapshot-ng/source
mkdir -p ~/rsnapshot-ng/source/somedir
touch ~/rsnapshot-ng/source/file1
touch ~/rsnapshot-ng/source/somedir/file2
mkdir -p ~/rsnapshot-ng/dest
cd ~/rsnapshot-ng/

Then copy the included script (at the bottom of this mail) to
~/rsnapshot-ng/rsnapshot-ng.sh, and run e.g:
bash rsnapshot-ng.sh daily 2
bash rsnapshot-ng.sh weekly 3

You should now have directories similar to the following, in
~/rsnapshot-ng/dest:
laptop.daily.201204040013
laptop.latest
laptop.monthly.201204040014

If you take a look at the script, you'll see that every backup job
writes to $SNAPSHOT_ROOT/$SNAPSHOT_NAME.$SNAPSHOT_SUBNAME.$DATE (using
$SNAPSHOT_ROOT/$SNAPSHOT_NAME.$SNAPSHOT_SUBNAME.latest as the
--link-dest DIR (rsync specific...)), then removes
$SNAPSHOT_ROOT/$SNAPSHOT_NAME.SNAPSHOT_SUBNAME.latest, before copying
the latest backup dir to
$SNAPSHOT_ROOT/$SNAPSHOT_NAME.SNAPSHOT_SUBNAME.latest with hardlinks.
Lastly it ensures that only the specified number of backups are kept
based on the $KEEP argument.

This solution ensures that the daily/weekly/monthly/etc backups are
actually up-to-date when created, and it also avoids most of the config
pecularities you'll have with rsnapshot.
There are still race condition issues when running multiple backup jobs
simulaniously, but I'm sure that could be solved just with some thought.

What do you guys think?

The actual script, rsnapshot-ng.sh (I threw this together, so bugs or
stupidness might occur):

#!/bin/bash
SOURCE=~/rsnapshot-ng/source
SNAPSHOT_ROOT=~/rsnapshot-ng/dest
SNAPSHOT_NAME=laptop
SNAPSHOT_SUBNAME=$1
KEEP=$2
DATE=`date +%Y%m%d%H%M`
DESTINATION="$SNAPSHOT_ROOT/$SNAPSHOT_NAME.$SNAPSHOT_SUBNAME.$DATE"
LATEST=$SNAPSHOT_NAME.latest

rsync -v -a --delete-excluded --delete --link-dest=../$LATEST $SOURCE
$DESTINATION
rm -r $SNAPSHOT_ROOT/$LATEST/
cp -al $DESTINATION $SNAPSHOT_ROOT/$LATEST/

# Keep only specified number of files matching $NAME.$SUBNAME* in
$BACKUP_ROOT
if [ -n "$KEEP" ]; then
/bin/ls -dt1 $SNAPSHOT_ROOT/$SNAPSHOT_NAME.$SNAPSHOT_SUBNAME* |
tail -n +$(($KEEP+1)) | xargs rm -r
fi

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 04, 2012 05:25AM
On Wed, Apr 04, 2012 at 01:50:01AM +0200, Espen wrote:

[quote]The way rsnapshot only syncs to the top-most interval/retain config
directory (e.g "daily"), while all the subsequent snapshot jobs (e.g.
"weekly"/"monthly") depends on the the first one in this list, is really
flawed, confusing and error prone in my opinion.

When running "rsnapshot weekly" when having "retain daily 3" at the top
in the config file, you'll get a weekly backup _only_ if daily.0 exists,
and regardless of when daily.0 was created.

If you no longer need daily backups, and decide to comment out
"rsnapshot daily" in cron, while forgetting to comment out "retain daily
NUM" in the config file, then your backup plan is completely borked!
[/quote]
Thankfully rsnapshot will tell you "snapshot_root/daily.2 not present
...", although this is a low priority message - priority 3, "show
shell commands and equivalents" where it should probably be priority 2
(the default) meaning "errors".

I've committed a change for this to CVS. In the meantime, turn your
verbosity up a bit to see the warning:

http://rsnapshot.cvs.sourceforge.net/viewvc/rsnapshot/rsnapshot/rsnapshot-program.pl?r1=1.430&r2=1.431

[quote]In addition to this, it also seems like it is very important to run the
cron daily/weekly/monthly jobs in the correct order, and with a
(uncertain) delay between each of them, in order for rsnapshot to work
correctly.
[/quote]
Provided you use_lazy_deletes there's no uncertainty.

[quote]I also dislike the way rsnapshot forces you to seperate arguments with
<TAB> in the config file.
[/quote]
So do I, but that's a very big change to make to code that has no real
test suite, and doubly so if you want to continue to support older
config files (or auto-convert them).

[quote]Especially because my editor (vim) expands all tabs to 4 spaces. It
would be much better if rsnapshot required quotes around the config
arguments that contains spaces.
[/quote]
Quoting is a whole world of hurt when you consider arguments that
might themselves contain quotes. That's why my experimental ground-up
rewrite uses an XML config file. This does, of course, introduce other
problems, as XML is just as annoying to write by hand!

[quote]I hope I'm not offending anyone, but large portions of the rsnapshot
code also seems old and outdated (atleast at first sight), and would
probably benefit alot from some simple refactoring, cleanup and
abstraction. I'm blaming this mostly on the age of the Perl code
(2003-2005).
[/quote]
Yes, you're right. I'm scared of cleaning up the code because it
*works* but has no real test suite, so the only way to make sure I don't
break anything is for me to write the test suite first. And to be blunt
I have more interesting things to do in my limited free time.

--
David Cantrell | Reality Engineer, Ministry of Information

Human Rights left unattended may be removed,
destroyed, or damaged by the security services.

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 04, 2012 06:07AM
Hallo, Espen,

Du meintest am 04.04.12:

[quote]The way rsnapshot only syncs to the top-most interval/retain config
directory (e.g "daily"), while all the subsequent snapshot jobs (e.g.
"weekly"/"monthly") depends on the the first one in this list, is
really flawed, confusing and error prone in my opinion.
[/quote]
Sorry - that's the only way I expect from a backup. If something has
changed, I expect these changes only in the actual backup, in no older
backup.

[quote]When running "rsnapshot weekly" when having "retain daily 3" at the
top in the config file, you'll get a weekly backup _only_ if daily.0
exists, and regardless of when daily.0 was created.
[/quote]
[quote]If you no longer need daily backups, and decide to comment out
"rsnapshot daily" in cron, while forgetting to comment out "retain
daily NUM" in the config file, then your backup plan is completely
borked!
[/quote]
The program cannot decide if I have forgotten this action or if I wish
this behaviour.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 04, 2012 08:29AM
On 2012-04-04, Espen wrote:

[quote]I also dislike the way rsnapshot forces you to seperate arguments with
<TAB> in the config file.
Especially because my editor (vim) expands all tabs to 4 spaces. It
would be much better if rsnapshot required quotes around the config
arguments that contains spaces.
[/quote]
One way to avoid having vim expand tabs to spaces in your
rsnapshot.conf files is to add a line like this at the bottom:

# vim: noexpandtab

To call attention to those spaces, I highlight them using this in
~/.vim/after/syntax/conf.vim (some of those lines may wrap):

" When using sudoedit to edit /etc/rsnapshot.conf, the actual editing is done
" to a temporary file (e.g., /var/tmp/rsnapshotXXqMRN4N.conf), so the
" condition below has to match the modified name.
"
if expand("<afile>:t") =~ "^rsnapshotk*.conf$"
" Paramter separators in /etc/rsnapshot.conf must be tabs, not spaces.
syn match rsnapshotParameterLine '^k+s+' contains=rsnapshotInvalidSeparator
syn match rsnapshotParameterLine '^k+s+S+s+' contains=rsnapshotInvalidSeparator
syn match rsnapshotInvalidSeparator ' ' contained containedin=rsnapshotParameterLine
endif

hi def link rsnapshotInvalidSeparator Error

HTH,
Gary

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 04, 2012 10:42AM
Sorry for the rudeness in my response, as well.

It sounds as if you set rsnapshot up, got it working, then fucked with
the configuration, and now you're pissed because you realize that it's
messed up and doesn't do what you want it to do without modification.
That's the wonderful thing---change it as you see fit.

My thoughts are interspersed.

On Tue, Apr 3, 2012 at 3:50 PM, Espen <espenx3 < at > gmail.com> wrote:
[quote]The way rsnapshot only syncs to the top-most interval/retain config
directory (e.g "daily"), while all the subsequent snapshot jobs (e.g.
"weekly"/"monthly") depends on the the first one in this list, is really
flawed, confusing and error prone in my opinion.
[/quote]
It's not at all, in my opinion.
It makes recovery easy, simple, and fast.
This is the expected behaviour, IMO.

[quote]When running "rsnapshot weekly" when having "retain daily 3" at the top
in the config file, you'll get a weekly backup _only_ if daily.0 exists,
and regardless of when daily.0 was created.
[/quote]
Why would that matter?
Daily's are run every day, or, as in my case, as often as possible.
Sometimes my daily backup takes 36 hours to run. Sometimes they take
an hour. I'm backing up somewhere between 6 terabytes and
200megabytes. I simply don't care what they're called---as long as
they run and rotate. The name is meaningless.

[quote]If you no longer need daily backups, and decide to comment out
"rsnapshot daily" in cron, while forgetting to comment out "retain daily
NUM" in the config file, then your backup plan is completely borked!
[/quote]
rsnapshot is not responsible for your failure to do things correctly
and with care.
It doesnt' know what you want unless you tell it.

[quote]In addition to this, it also seems like it is very important to run the
cron daily/weekly/monthly jobs in the correct order, and with a
(uncertain) delay between each of them, in order for rsnapshot to work
correctly.
[/quote]
Indeed. This is well documented. Perhaps large red letters in the
docs would help?
01 05 * * * root /usr/bin/rsnapshot daily
01 04 * * 6 root /usr/bin/rsnapshot weekly
01 03 1 * * root /usr/bin/rsnapshot monthly

[quote]I also dislike the way rsnapshot forces you to seperate arguments with
<TAB> in the config file.
Especially because my editor (vim) expands all tabs to 4 spaces. It
would be much better if rsnapshot required quotes around the config
arguments that contains spaces.
[/quote]
This would require a lot of changes to the code.
Quotes aren't good in configurations, for the obvious reasons.
Besides, as has been mentioned, vim does handle tabs.

[quote]I hope I'm not offending anyone, but large portions of the rsnapshot
code also seems old and outdated (atleast at first sight), and would
probably benefit alot from some simple refactoring, cleanup and
abstraction. I'm blaming this mostly on the age of the Perl code
(2003-2005).
[/quote]
This is true. However, the developers are unwilling to change things
because right now, it works and is VERY stable.

[quote]And..
Why should you have to specify "retain daily 3", "retain weekly 4", and
so on, in the config when you'll have to create seperate cron-jobs for
all of these anyway?
It doesn't make sense?
[/quote]
It does from a server standpoint, but certainly not a machine that's
turned on and off.
It also make sense when you have machines with massive amounts of
data, such as mine, that sometimes take longer to back up than the
interval time. My initial backup took 9 weeks to run. That's not a
typo. Obviously, the rsync had to be run by hand several times. I
would *MUCH* rather rely on the lock than anything else. I know it
won't do duplicate runs if it's locked, so.......

122T /storage/pangea_snapshots/daily.0/
452G /storage/pangea_snapshots/daily.1/
940G /storage/pangea_snapshots/daily.2/
922G /storage/pangea_snapshots/daily.3/
23G /storage/pangea_snapshots/daily.4/
733G /storage/pangea_snapshots/daily.5/
824G /storage/pangea_snapshots/daily.6/
567G /storage/pangea_snapshots/daily.7/

(daily.4 was stopped on purpose, ignore that...)

Anyway, you propose interesting ideas, I'd say implement things as
they work for you.

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 04, 2012 07:57PM
On 04/04/2012 07:50 AM, Espen wrote:
[quote]And..
Why should you have to specify "retain daily 3", "retain weekly 4", and
so on, in the config when you'll have to create seperate cron-jobs for
all of these anyway?
It doesn't make sense?
[/quote]Can think of one UC for this. The period at which you transfer a backup
to a lower level, N+1, does not equal the number of backups at N. E.g.
three backups with daily frequency, and one with monthly. Of course the
syntax could be changed to:

retain <label> <N> <M>

Where <N> is the number of backups (or size of buffer) at this level and
<M> is when to pull or alternately push a backup from/to the upper/lower
level (buffer) respectively. But actually specifying this in the crontab
or manually seems more verbose and maluable, and probably serves another
UC where you just want to force a given rotation for some reason.

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 05, 2012 02:23AM
On 04/04/12 00:50, Espen wrote:
[quote]Hi.

Sorry for the rudeness in the summary.
rsnapshot is offcourse very usable, and it handles backup jobs for heaps
of people without problems!

I've been looking for a sane backup-tool to do my incremental backups to
a remote machine...
[/quote]
An alternative to rsnapshot is brandysnap, which I wrote because I found
rsnapshot to be awkward in some situations, especially when backups
aren't always able to be made at the expected times.

Brandysnap is not complete yet, but it's usable (at your own risk, as
with any open source software). It's available at:

https://github.com/StarsoftAnalysis/brandysnap

cheers

Chris
--
Chris Dennis cgdennis < at > btinternet.com
Fordingbridge, Hampshire, UK

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 05, 2012 02:37AM
On Thu, Apr 5, 2012 at 11:22 AM, Chris Dennis <cgdennis < at > btinternet.com> wrote:
[quote]On 04/04/12 00:50, Espen wrote:
[quote]Hi.

Sorry for the rudeness in the summary.
rsnapshot is offcourse very usable, and it handles backup jobs for heaps
of people without problems!

I've been looking for a sane backup-tool to do my incremental backups to
a remote machine...
[/quote]
An alternative to rsnapshot is brandysnap, which I wrote because I found
rsnapshot to be awkward in some situations, especially when backups
aren't always able to be made at the expected times.

Brandysnap is not complete yet, but it's usable (at your own risk, as
with any open source software).  It's available at:

   https://github.com/StarsoftAnalysis/brandysnap
[/quote]
I personnally do not use rsnapshot because the daily.0 does not mean
anything to the end user.

Furthermore, it is written in Perl.

I use ccollect, written in shell, which makes it usable on small
devices running openwrt:

http://www.nico.schottelius.org/software/ccollect/

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 05, 2012 03:02AM
Hallo, Benjamin,

Du meintest am 05.04.12:

[quote]I personnally do not use rsnapshot because the daily.0 does not mean
anything to the end user.
[/quote]
Feel free to use any other name(s) for the intervals in "/etc/
rsnapshot.conf", p.e.

peter
paul
mary

or
one
two
three

or something else.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 05, 2012 04:06AM
On 05/04/12 10:36, Benjamin Henrion wrote:
[quote]I personnally do not use rsnapshot because the daily.0 does not mean
anything to the end user.

Furthermore, it is written in Perl.

I use ccollect, written in shell, which makes it usable on small
devices running openwrt:

http://www.nico.schottelius.org/software/ccollect/
[/quote]
Thanks for that link -- I haven't seen ccollect before, and it looks
interesting.

cheers

Chris
--
Chris Dennis cgdennis < at > btinternet.com
Fordingbridge, Hampshire, UK

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 05, 2012 04:29AM
[ Accidentally sent just to Benjamin!! ]

On Thu, Apr 5, 2012 at 5:36 AM, Benjamin Henrion <bh < at > udev.org ([email]bh < at > udev.org[/email])> wrote:
[quote] On Thu, Apr 5, 2012 at 11:22 AM, Chris Dennis <cgdennis < at > btinternet.com ([email]cgdennis < at > btinternet.com[/email])> wrote:
[quote]On 04/04/12 00:50, Espen wrote:
[quote]Hi.

Sorry for the rudeness in the summary.
rsnapshot is offcourse very usable, and it handles backup jobs for heaps
of people without problems!

I&#39;ve been looking for a sane backup-tool to do my incremental backups to
a remote machine...
[/quote]
An alternative to rsnapshot is brandysnap, which I wrote because I found
rsnapshot to be awkward in some situations, especially when backups
aren&#39;t always able to be made at the expected times.

Brandysnap is not complete yet, but it&#39;s usable (at your own risk, as
with any open source software).  It&#39;s available at:

   [url=https://github.com/StarsoftAnalysis/brandysnap]https://github.com/StarsoftAnalysis/brandysnap[/url]
[/quote]

I personnally do not use rsnapshot because the daily.0 does not mean
anything to the end user.

[/quote]
I do believe he mans the ".0", which is missing legible information about when the dump was made. It&#39;s particularly confusing when the backups are intermittent because the targets are confusing: digging for the timestamps is awkward, and easily corrupted by copy operations.
 
Some folks have suggested putting time information in that suffix, and I&#39;d favor it. But I&#39;ve not found the time to write that into something nthat works well enough for me as it is.
rsnapshot is flawed.
April 05, 2012 06:08AM
Hallo, Nico,

Du meintest am 05.04.12:

[quote]Some folks have suggested putting time information in that suffix,
and I'd favor it.
[/quote]
Sorry - why?
The directory has a time stamp.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 09, 2012 08:56PM
On Thu, Apr 5, 2012 at 8:30 AM, Helmut Hullen <Hullen < at > t-online.de ([email]Hullen < at > t-online.de[/email])> wrote:
[quote]
Hallo, Nico,

Du meintest am 05.04.12:

[quote]Some folks have suggested putting time information in that suffix,
and I&#39;d favor it.
[/quote]
Sorry - why?
The directory has a time stamp.

Viele Gruesse!
Helmut

[/quote]This is an old issue. For me, it would ease trying to restore a tape or other copy of an old backup and being sure not to overwrite it. Also, if I point someone to "daily.20120409-120304", that&#39;s likely to be the same backup for me to pull files from, no matter if they happen to wait a day to look at it. And when attempting to recover files with scp, sftp, rsync, or numerous other technologies, it&#39;s extra labor to have to peruse the top of the directory tree just to find out when the backup was done.
 
 
rsnapshot is flawed.
April 09, 2012 09:08PM
Hallo, Nico,

Du meintest am 09.04.12:

[quote][quote][quote]Some folks have suggested putting time information in that suffix,
and I'd favor it.
[/quote][/quote][/quote]
[quote][quote]Sorry - why?
The directory has a time stamp.
[/quote][/quote]
[quote]This is an old issue.
[/quote]
Yes - I know.
If someone really wants this information not only in the time stamp but
in the directory name too he can use a symlink (and that's no simple
job).

One job for "rsnapshot" is renumbering the backups. That's a nasty job
when there is more to do than only changing the suffixes.

Showing the time stamps is mostly the job of a file manager; on Windows
systems p.e. "Windows Explorer", on Linux systems something like
"midnight commander". Working with files from a backup needs working
with a file manager.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 07:18AM
Hallo, Nico,

Du meintest am 10.04.12:

[quote][quote][quote][quote][quote]Some folks have suggested putting time information in that
suffix, and I'd favor it.
[/quote][/quote][/quote][/quote][/quote]
[quote][quote][quote][quote]Sorry - why?
The directory has a time stamp.
[/quote][/quote][/quote][/quote]
[...]

[quote][quote]One job for "rsnapshot" is renumbering the backups. That's a nasty
job when there is more to do than only changing the suffixes.
[/quote][/quote]
[quote]And completely unnecessary if you've got timestamps in the backup
names.
[/quote]
Can you please show the program lines (shell or perl or pseudo code) for
this job? Renumbering not the extensions of (p.e.) "daily.x" but
renumbering/shifting somethink like "daily-20120408"? Especially
shifting "daily-xyz" to "weekly-uvw"?

Thank you!

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 07:29AM
On Tue, Apr 10, 2012 at 6:07 AM, Helmut Hullen <Hullen < at > t-online.de> wrote:
[quote]Hallo, Nico,

Du meintest am 09.04.12:

[quote][quote][quote]Some folks have suggested putting time information in that suffix,
and I'd favor it.
[/quote][/quote][/quote]
[quote][quote]Sorry - why?
The directory has a time stamp.
[/quote][/quote]
[quote]This is an old issue.
[/quote]
Yes - I know.
If someone really wants this information not only in the time stamp but
in the directory name too he can use a symlink (and that's no simple
job).

One job for "rsnapshot" is renumbering the backups. That's a nasty job
when there is more to do than only changing the suffixes.

Showing the time stamps is mostly the job of a file manager; on Windows
systems p.e. "Windows Explorer", on Linux systems something like
"midnight commander". Working with files from a backup needs working
with a file manager.
[/quote]
That's really dirt to push back the problem to the filesystem.

If I want to look for a timestamp, the last place where I would look
is in the contents of "ls".

Furthermore, it is not reliable if you copy the backup to another
filesystem (which is a pretty common case if you want to rescue
something).

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 08:02AM
On 04/10/2012 04:16 PM, Helmut Hullen wrote: [quote] [quote]Hallo, Nico,

Du meintest am 10.04.12:

[quote] [quote] [quote] [quote] [quote]Some folks have suggested putting time information in that
suffix, and I'd favor it.
[/quote] [/quote] [/quote] [/quote] [/quote]
[quote] [quote] [quote] [quote]Sorry - why?
The directory has a time stamp.
[/quote] [/quote] [/quote] [/quote]
[...]

[quote] [quote]One job for "rsnapshot" is renumbering the backups. That's a nasty
job when there is more to do than only changing the suffixes.
[/quote] [/quote]
[quote]And completely unnecessary if you've got timestamps in the backup
names.
[/quote]
Can you please show the program lines (shell or perl or pseudo code) for
this job? Renumbering not the extensions of (p.e.) "daily.x" but
renumbering/shifting somethink like "daily-20120408"? Especially
shifting "daily-xyz" to "weekly-uvw"?
[/quote] [/quote] Why would you have to rename/renumber/shift anything when they are timestamped?

Just delete the oldest. The simple shell script I included in the original post, does that:

# Keep only specified number of dirs matching $NAME.$SUBNAME* in $BACKUP_ROOT
if [ -n "$KEEP" ]; then
[i]/bin/ls -dt1 $SNAPSHOT_ROOT/[/i]$SNAPSHOT_NAME.$SNAPSHOT_SUBNAME* | tail -n +$(($KEEP+1)) | xargs rm -r
fi

[quote] [quote]
Thank you!

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
[url=http://p.sf.net/sfu/Boundary-dev2dev]http://p.sf.net/sfu/Boundary-dev2dev[/url]
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net ([email]rsnapshot-discuss < at > lists.sourceforge.net[/email])
[url=https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss]https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss[/url]
[/quote] [/quote]
rsnapshot is flawed.
April 10, 2012 08:17AM
On 04/04/2012 02:55 PM, Helmut Hullen wrote:
[quote]Hallo, Espen,

Du meintest am 04.04.12:

[quote]The way rsnapshot only syncs to the top-most interval/retain config
directory (e.g "daily"), while all the subsequent snapshot jobs (e.g.
"weekly"/"monthly") depends on the the first one in this list, is
really flawed, confusing and error prone in my opinion.
[/quote]Sorry - that's the only way I expect from a backup. If something has
changed, I expect these changes only in the actual backup, in no older
backup.
[/quote]I don't see how my proposed solution doesn't do this already?
If you read my post again, you'll see that it uses the same hardlinking
mechanisms as rsnapshot.

[quote][quote]When running "rsnapshot weekly" when having "retain daily 3" at the
top in the config file, you'll get a weekly backup _only_ if daily.0
exists, and regardless of when daily.0 was created.
If you no longer need daily backups, and decide to comment out
"rsnapshot daily" in cron, while forgetting to comment out "retain
daily NUM" in the config file, then your backup plan is completely
borked!
[/quote]The program cannot decide if I have forgotten this action or if I wish
this behaviour.
[/quote]It can't, but backup tools should in general limit the possibility of
screwing up things.
rsnapshot does alot of that already, but it (currently) fails silently
if you mess up this setting.

[quote]Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
[/quote]

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 08:17AM
Hallo, Espen,

Du meintest am 10.04.12:

[quote][quote][quote][quote]One job for "rsnapshot" is renumbering the backups. That's a nasty
job when there is more to do than only changing the suffixes.
[/quote]And completely unnecessary if you've got timestamps in the backup
names.
[/quote]Can you please show the program lines (shell or perl or pseudo code)
for this job? Renumbering not the extensions of (p.e.) "daily.x" but
renumbering/shifting somethink like "daily-20120408"? Especially
shifting "daily-xyz" to "weekly-uvw"?
[/quote]Why would you have to rename/renumber/shift anything when they are
timestamped?
[/quote]
[quote]Just delete the oldest.
[/quote]
That goes wrong.

When I start a completely new "rsnapshot" directory then "daily",
"weekly" and "monthly" are empty. And when I rename the oldest "hourly"
backup to "daily" then this first "daily" directory is the oldest and
has to be deleted.

That goes wrong also when there are gaps.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 08:17AM
Hallo, Benjamin,

Du meintest am 10.04.12:

[quote][quote][quote][quote]The directory has a time stamp.
[/quote][/quote][/quote][/quote]
[quote]If I want to look for a timestamp, the last place where I would look
is in the contents of "ls".
[/quote]
[quote]Furthermore, it is not reliable if you copy the backup to another
filesystem (which is a pretty common case if you want to rescue
something).
[/quote]
Putting a string which looks like a time string into the directory name
is also unreliable.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 08:25AM
On 04/10/2012 05:14 PM, Helmut Hullen wrote:
[quote]Hallo, Espen,

Du meintest am 10.04.12:

[quote][quote][quote][quote]One job for "rsnapshot" is renumbering the backups. That's a nasty
job when there is more to do than only changing the suffixes.
[/quote]And completely unnecessary if you've got timestamps in the backup
names.
[/quote]Can you please show the program lines (shell or perl or pseudo code)
for this job? Renumbering not the extensions of (p.e.) "daily.x" but
renumbering/shifting somethink like "daily-20120408"? Especially
shifting "daily-xyz" to "weekly-uvw"?
[/quote]Why would you have to rename/renumber/shift anything when they are
timestamped?
Just delete the oldest.
[/quote]That goes wrong.

When I start a completely new "rsnapshot" directory then "daily",
"weekly" and "monthly" are empty. And when I rename the oldest "hourly"
backup to "daily" then this first "daily" directory is the oldest and
has to be deleted.

That goes wrong also when there are gaps.
[/quote]Read my post again. My suggested alogorithm doesn't rename "hourly" to
"weekly" or whatever.
Every hourly/daily/weekly backups are independent of each other, and
they are actually up-to-date when created.
Unlike how rsnapshot does it.

I don't see how it would behave worse with gaps compared to how
rsnapshot already works today, but please enlighten me.
[quote]Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
[/quote]

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 08:25AM
On Tue, Apr 10, 2012 at 5:09 PM, Helmut Hullen <Hullen < at > t-online.de> wrote:
[quote]Hallo, Benjamin,

Du meintest am 10.04.12:

[quote][quote][quote][quote]The directory has a time stamp.
[/quote][/quote][/quote][/quote]
[quote]If I want to look for a timestamp, the last place where I would look
is in the contents of "ls".
[/quote]
[quote]Furthermore, it is not reliable if you copy the backup to another
filesystem (which is a pretty common case if you want to rescue
something).
[/quote]
Putting a string which looks like a time string into the directory name
is also unreliable.
[/quote]
It is more reliable then relying on the filesystem.

But you have to choose to use the start or the finish time of the
backup process.

Furthermore, ccollect uses microseconds to make the dirname pretty unique:

daily.20120313-2101.30390-1
daily.20120314-2101.1292-1

--
Benjamin Henrion <bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 08:31AM
On 04/10/2012 05:14 PM, Helmut Hullen wrote:
[quote]Hallo, Espen,

Du meintest am 10.04.12:

[quote][quote][quote][quote]One job for "rsnapshot" is renumbering the backups. That's a nasty
job when there is more to do than only changing the suffixes.
[/quote]And completely unnecessary if you've got timestamps in the backup
names.
[/quote]Can you please show the program lines (shell or perl or pseudo code)
for this job? Renumbering not the extensions of (p.e.) "daily.x" but
renumbering/shifting somethink like "daily-20120408"? Especially
shifting "daily-xyz" to "weekly-uvw"?
[/quote]Why would you have to rename/renumber/shift anything when they are
timestamped?
Just delete the oldest.
[/quote]That goes wrong.

When I start a completely new "rsnapshot" directory then "daily",
"weekly" and "monthly" are empty. And when I rename the oldest "hourly"
backup to "daily" then this first "daily" directory is the oldest and
has to be deleted.
[/quote]Just to clarify:

imaginary config setting:
retain daily 5

Pseudo code:
for $file (sort_by_date(list_backup_dir()) {
$filenum++;
delete $file if $filenum > $retain_num;
}

Pretty simple.
1. list the directory sorted by da
[quote]That goes wrong also when there are gaps.

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
[/quote]

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 08:46AM
On 04/04/2012 07:40 PM, Ken Woods wrote:
[quote]Sorry for the rudeness in my response, as well.

It sounds as if you set rsnapshot up, got it working, then fucked with
the configuration, and now you're pissed because you realize that it's
messed up and doesn't do what you want it to do without modification.
That's the wonderful thing---change it as you see fit.

[/quote]Yep, you're right :)
Well, I actually discovered this when trying to deterimine if rsnapshot
is well behaved.

[quote]My thoughts are interspersed.

On Tue, Apr 3, 2012 at 3:50 PM, Espen<espenx3 < at > gmail.com> wrote:
[quote]The way rsnapshot only syncs to the top-most interval/retain config
directory (e.g "daily"), while all the subsequent snapshot jobs (e.g.
"weekly"/"monthly") depends on the the first one in this list, is really
flawed, confusing and error prone in my opinion.
[/quote]It's not at all, in my opinion.
It makes recovery easy, simple, and fast.
This is the expected behaviour, IMO.

[/quote]The point is that the way it works today is uneccesary confusing and
vulnarable.
There are alot of other posts to this mailing list addressing the exact
same issues.
Recovery with my suggested solution is also as easy, simple and fast.
[quote][quote]When running "rsnapshot weekly" when having "retain daily 3" at the top
in the config file, you'll get a weekly backup _only_ if daily.0 exists,
and regardless of when daily.0 was created.
[/quote][/quote]Becuase it's not a weekly backup. It's a weekly copy of whatever daily.0
contains.
"rsnapshot daily" and "rsnapshot weekly" does different things because
if this dependency on eachother.
[quote]Why would that matter?
Daily's are run every day, or, as in my case, as often as possible.
Sometimes my daily backup takes 36 hours to run. Sometimes they take
an hour. I'm backing up somewhere between 6 terabytes and
200megabytes. I simply don't care what they're called---as long as
they run and rotate. The name is meaningless.

[/quote]Even because you _can_ name the backups whatever you want, doesn't mean
that it is sane to do so.
The way each retain setting depends on the one above it strongly suggest
that you should name them something that is visually sortable: daily,
weekly, monthly - one, two, three - etc.
[quote][quote]"rsnapshot daily" in cron, while forgetting to comment out "retain daily
NUM" in the config file, then your backup plan is completely borked!
[/quote]rsnapshot is not responsible for your failure to do things correctly
and with care.
It doesnt' know what you want unless you tell it.

[quote]In addition to this, it also seems like it is very important to run the
cron daily/weekly/monthly jobs in the correct order, and with a
(uncertain) delay between each of them, in order for rsnapshot to work
correctly.
[/quote]Indeed. This is well documented. Perhaps large red letters in the
docs would help?
[/quote]Perhaps...
[quote]01 05 * * * root /usr/bin/rsnapshot daily
01 04 * * 6 root /usr/bin/rsnapshot weekly
01 03 1 * * root /usr/bin/rsnapshot monthly

[quote]I also dislike the way rsnapshot forces you to seperate arguments with
<TAB> in the config file.
Especially because my editor (vim) expands all tabs to 4 spaces. It
would be much better if rsnapshot required quotes around the config
arguments that contains spaces.
[/quote]This would require a lot of changes to the code.
Quotes aren't good in configurations, for the obvious reasons.
Besides, as has been mentioned, vim does handle tabs.

[/quote]Haven't really given this much thought, but i know bash and Getopt for
perl already does well with e.g command line arguments enclosed in
quotes, or arguments with escaped meta characters.
[quote][quote]I hope I'm not offending anyone, but large portions of the rsnapshot
code also seems old and outdated (atleast at first sight), and would
probably benefit alot from some simple refactoring, cleanup and
abstraction. I'm blaming this mostly on the age of the Perl code
(2003-2005).
[/quote]This is true. However, the developers are unwilling to change things
because right now, it works and is VERY stable.

[quote]And..
Why should you have to specify "retain daily 3", "retain weekly 4", and
so on, in the config when you'll have to create seperate cron-jobs for
all of these anyway?
It doesn't make sense?
[/quote]It does from a server standpoint, but certainly not a machine that's
turned on and off.
It also make sense when you have machines with massive amounts of
data, such as mine, that sometimes take longer to back up than the
interval time. My initial backup took 9 weeks to run. That's not a
typo. Obviously, the rsync had to be run by hand several times. I
would *MUCH* rather rely on the lock than anything else. I know it
won't do duplicate runs if it's locked, so.......

122T /storage/pangea_snapshots/daily.0/
452G /storage/pangea_snapshots/daily.1/
940G /storage/pangea_snapshots/daily.2/
922G /storage/pangea_snapshots/daily.3/
23G /storage/pangea_snapshots/daily.4/
733G /storage/pangea_snapshots/daily.5/
824G /storage/pangea_snapshots/daily.6/
567G /storage/pangea_snapshots/daily.7/

(daily.4 was stopped on purpose, ignore that...)

Anyway, you propose interesting ideas, I'd say implement things as
they work for you.
[/quote]

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 10, 2012 08:48AM
On 04/05/2012 11:36 AM, Benjamin Henrion wrote:
[quote]On Thu, Apr 5, 2012 at 11:22 AM, Chris Dennis<cgdennis < at > btinternet.com> wrote:
[quote]On 04/04/12 00:50, Espen wrote:
[quote]Hi.

Sorry for the rudeness in the summary.
rsnapshot is offcourse very usable, and it handles backup jobs for heaps
of people without problems!

I've been looking for a sane backup-tool to do my incremental backups to
a remote machine...
[/quote]An alternative to rsnapshot is brandysnap, which I wrote because I found
rsnapshot to be awkward in some situations, especially when backups
aren't always able to be made at the expected times.

Brandysnap is not complete yet, but it's usable (at your own risk, as
with any open source software). It's available at:

https://github.com/StarsoftAnalysis/brandysnap
[/quote]I personnally do not use rsnapshot because the daily.0 does not mean
anything to the end user.

Furthermore, it is written in Perl.

I use ccollect, written in shell, which makes it usable on small
devices running openwrt:

http://www.nico.schottelius.org/software/ccollect/
[/quote]
Very nice
I've done alot of searching, but I din't find this one.
Thanks!

[quote]--
Benjamin Henrion<bhenrion at ffii.org>
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
[/quote]

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 11, 2012 04:02AM
On Tue, Apr 10, 2012 at 04:28:19PM +0200, Benjamin Henrion wrote:

[quote]That's really dirt to push back the problem to the filesystem.

If I want to look for a timestamp, the last place where I would look
is in the contents of "ls".

Furthermore, it is not reliable if you copy the backup to another
filesystem (which is a pretty common case if you want to rescue
something).
[/quote]
I won't accept a patch to change from using numbered suffices to
date/time stamped filenames, even if it's just as a non-default option.
I doubt any of the others with commit priveleges will either.

I *will* accept a separate tool which maintains a bunch of symlinks so
that, eg, ...

2012-04-11T11:55:03 -> daily.0
2012-04-10T11:56:32 -> daily.1
...

If you think this is so important, then I expect your code presently and
I'll add it to CVS.

--
David Cantrell | Cake Smuggler Extraordinaire

Vegetarian: n: a person who, due to malnutrition caused by
poor lifestyle choices, is eight times more likely to
catch TB than a normal person

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
rsnapshot is flawed.
April 11, 2012 05:00AM
Hallo, David,

Du meintest am 11.04.12:

[quote]I won't accept a patch to change from using numbered suffices to
date/time stamped filenames, even if it's just as a non-default
option. I doubt any of the others with commit priveleges will either.
[/quote]
Thank you!

Viele Gruesse!
Helmut

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
rsnapshot-discuss mailing list
rsnapshot-discuss < at > lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rsnapshot-discuss
Sorry, only registered users may post in this forum.

Click here to login