Release notes for Excito Bubba 2&3 software version 2.6

[Ubi]

I never really looked at rdiff and doing so now it seems to me like a poor men's NetWare volume. I think the hard link copy approach combined with rsync is still better,

I was always under the impression rdiff-backup was using rsync with hard links under the hood and was merely acting as a nice frontend to this. If it indeed works like you describe you have a very strong point.

[Ubi]

argh now I get it: I was thinking about rsnapshot instead
http://www.rsnapshot.org/

rdiff-backup is indeed terrible as it make undecipherable diff files. Apologies for not looking at this earlier. If y'all be so kind to mentally replace rdiff-backup with rsnapshot in my previous posts that would be real good

[Gordon]

That's more like it

[Gordon]

Ubi,

Did you know that rsnapshot is actually in the repository? A bit fishy however, because the package has a dependency on a perl module that you shouldn't use. If Excito ever chooses for this backup routine they should definitely get rid of this dependency and list the correct paths in the rsnapshot config file (all the external applications required are the preferred GNU versions).

Have to say though that I don't really like the naming convention they're using. For instance if I'd want to retrieve a file from last Monday, I like to get that from a directory that is labelled accordingly rather then daily dot (minus) 2 (the most recent `daily.0` would in fact be yesterday). Same with months: February should be labelled similarly or as "02", not as last month minus 4. It's confusing and I actually changed that last `4` about six times, but I'm fairly confident now that 4 is correct.

[Ubi]

Yeah I ran into this as well. Before rsnapshot came about I wrote my own wrapper in python, so I never had any real use for it myself. But I like vendors to use established tools as opposed to developing your own and then abandoning it like we saw with FTD and magnet links. It took ages for excito to release the source for FTD despite it being GPL (due to usage of gpl libs).
I actually like their naming convention, but I can imagine why somebody else would not. In my experience, user generally know they had the file about 3 monts ago, and their naming convention makes restoring from shell a bit easier.

[Gordon]

Ah, but there you're wrong. Because it is in fact Excito (or OpenProducts) that you want to write a web based frontend to plug into their main administration pages. Since rbackup itself is a wrapper around rsync, it would make more sense to base the development of the web wrapper on rsync itself than on a shell based wrapper for it that is maintained by another developer and except for the initial idea of adding rotation mainly targets to mimic what the B3 can do out of the box.

[Ubi]

not really, because they are replicating efforts already taken 6 years ago by others. That earlier effort has a larger userbase, the code has been scrutinized for multiple years and is well documented. Again, think FTD. Your argument would be that writing a new frontend to the bittorrent libs would have been better than just plugging in transmission. ANd then why does the B3 feature RoundCube or Horde, which are just wrappers around dovecot.

[Gordon]

not really, because they are replicating efforts already taken 6 years ago by others. That earlier effort has a larger userbase, the code has been scrutinized for multiple years and is well documented. Again, think FTD. Your argument would be that writing a new frontend to the bittorrent libs would have been better than just plugging in transmission. ANd then why does the B3 feature RoundCube or Horde, which are just wrappers around dovecot.

Not true. Dovecot is an IMAP server while Roundcube and Horde are web/PHP based IMAP clients. FTD is a totally different matter, since this is a binary development. Rbackup on the other hand is a script built around binaries that may or may not offer the full functionality required with the script being able to mimic the desired behaviour for what is not supported by the available binaries.

So yes, while the rbackup development in itself may be sane, most of what the script offers will never be used because the binaries on the B3 can in fact do all that is desired. From a B3 developer's point of view there's therefore simply no difference in calling `rbackup monthly` or `cp -al <backup_root/yesterday> <backup_root/year/month>`

Frankly I don't get why the rbackup developers chose to let you call this specifically through a separate cron job, when it's hardly any effort to script whether at some point you should create an additional hardlink copy (or possibly more than one) based on what is in the config file.

[Ubi]

Most users cannot script

[Gordon]

Most users cannot script

I don't follow

[Ubi]

Id say all has been said whilst going completely ot. Id suggest a pm if you wish to continue this duscussion further

[ingo2]

Sorry to interrupt your thoughts.

Ever thoght of 'dirvish', a package which is in the Debian repositories ans does all we/you want. It uses hardlinks and rsync to do differential backups and can be easily configured to ones needs. Can be operated via GUI and commands/cron jobs. Besides local backups it also can handle remote backups - even via secure ssh.

Link is http://packages.debian.org/de/wheezy/dirvish. I used it for years on my desktop - absolutely reliable.

BTW: is there any detailled changelog for the 2.6 update?

Best regards,
Ingo

[ingo2]

Sorry to interrupt your thoughts.

Ever thought of 'dirvish', a package which is in the Debian repositories ans does all we/you want. It uses hardlinks and rsync to do differential backups and can be easily configured to ones needs. Can be operated via GUI and commands/cron jobs. Besides local backups it also can handle remote backups - even via secure ssh.

Link is http://packages.debian.org/de/wheezy/dirvish. I used it for years on my desktop - absolutely reliable.

BTW: is there any detailled changelog for the 2.6 update?

Best regards,
Ingo

[Gordon]

Dirvish does ring a bell, but I can't remember the specifics off hand. The whole point however is that the backup functionality should be a core functionality of the B3 and therefore be an integral part of the B3 admin interface. Dirvish, while it may be great, should be an advanced user's choice to do something outside of the basic functionality that the B3 offers.

The core discussion as I see it is about a feature request that involves building and integrating a web based wrapper around a basically simple existing wrapper and I don't think that makes much sense. I would see the point if the original wrapper would do really complex stuff, but the fact is that it doesn't and as I explained its naming convention may cause somewhat of an issue for a user who hasn't reached the guru level.

[Ubi]

afaik dirvish is yet another implementation of the legendary 'automated snapshots using rsync' post from long ago. It has some extra bells and whistles, but personally I dislike the syntax of the config files, as it uses non-intuitive names like 'vault'.