Release notes for Excito Bubba 2&3 software version 2.6

[gonk]

Sorry you are not happy with the new backup.

Well, if you replace a proper backup solution with one providing a replica of files to another disk or location without the possibility to recover files having been deleted or changed, just what's currently on the replica media then I think that many will feel like I.

If Duplicity, or your implementation of functionality based on Duplicity, was not perfect (one major problem was that it was set up to compress the backup media which is pretty useless since allmost all data formats are already compressed) then replacing it with something that will not even be close to the same is not good.

Nowdays the typical B3 user backs up their photo collection (could be 1 TB or more), and for that, timeline feature is useless.

Why do you think that a timeline is useless for a photo collection?
I am a photographer and really prefer that solution to just having what-was-replicated-the-last-time approach.

What then about being able ro restore a file in the the /storage/web folder that my wife happened to delete or to revert to an older version of /home/myuser/bin/cool-script.sh?

Furthermore, restoring from a tree of multiple delta backups gets very heavy, and with large datasets it does not work properly on the B3. Due to the high number of issue reports on the backup we felt that it could not be trusted.

Removing features is not solving problems. It's like accepting that the doctor amputates your foot instead of giving you the correct treatment.

[toukie]

One problem emerged.

I have a Mac in front of B3. In the previous versions of B3 /home/web was included in User share and all the other users as well. It was easy to drop files from Mac to foldes in /home/web and to manage anything else I had there, like for instance WordPress. Now there is a folder with the content of one user only and no access to the folders in /home/web or to other users.

How can I get back the fast and practical interface that was there up till version 2.6 ?

[toukie]

I guess that the file where I could include /home/web in order to get it working as it was before the update is this: /etc/bubba/AppleVolumes.default

This is the end of the file:

# The line below sets some DEFAULT, starting with Netatalk 2.1.
EFAULT: options:upriv,usedots

# By default all users have access to their home directories.
/home/.TimeMachine "TimeMachine" options:tm allow:@users rwlist:@users
/home/$u/ "User share for $u" cnidscheme:dbd dbpath:/var/lib/netatalk/$v allow:@users rwlist:@users $
/home/storage/ "Public share" cnidscheme:dbd dbpath:/var/lib/netatalk/$v rwlist:@users fperm:0664 dp$
# End of File

Those folders are there. In earlier versions of B3 even /home/web was in "User share"

How should I write in /home/web to that file? When it was included in earlier versions I could drag and drop files easily to /home/web, write in different alphabets, things that don't even work, or work badly by command line on Mac. It was fast and simple way to manage things. I would like to have it back.

If this was a "security enhancement" I don't need it. I have no wife or children who are playing around with my B3.

[toukie]

I solved my problem and got back the interface on Mac that gives access to B3 /home/web in User share (In version 2.6 you get access only to a specific user)

In /etc/bubba/AppleVolumes.default change back to how it was in previous versions.

Do this: /home/ "User share" cnidscheme:dbd dbpath:/var/lib/netatalk allow:@users rwlist:@users fperm:0644 dperm:0755

instead of the new one: /home/$u/ "User share for $u" cnidscheme:dbd dbpath:/var/lib/netatalk/$v allow:@users rwlist:@users fperm:0644 dperm:0755

By the way, the editing function seems to have disappeared from this forum.

[ingo2]

Luckily I have read this thread before applying the upgrade.

One important question arises now since you switched to 'rsync' :

how is 'rsync' used:
a) is it run by scripts similar to 'copy' or
b) is it running as a daemon?

Latter could interfere with my current setup, because I have already 'rsync' running as a daemon with different "modules" for remote access/usage on my B3.

Kind regards,
Ingo

[Ubi]

In this case the rsync is local-to-local, so it does make any sense to use a daemon.

[mih]

Therefor, a much more simplistic approach was chosen, and most customers now think sync is a nicer approach than backup, for instance it is comforting to be able to see all data directly on the target. We have had many worried customers asking why their data was "garbled" on target (duplicity compresses it, chunks it and "deltas" it). For instance a clean sync ensures restoring without the need for a working B3, if this would ever be needed.

From my personal experience with backup systems on device with similar specs as the B3: You may want to go for rdiff-backup (http://packages.debian.org/sid/rdiff-backup). It essentially works like rsync, but (optionally) gives you the timeline feature, while preserving the pristine data structure of the latest backup version (i.e. you can just go into the directory and copy stuff back).

As far as I am concerned as single copy is not a sufficient backup -- even for home users. It can happen way to easy to accidentally delete/corrupt/modify a file. With the current frontend options, users have no way to retrieve a backup of such a file after a week (at most).

Michael

[Ubi]

I second this motion. Implementing rdiff-backup is a good idea in terms of excito devtime (its a mature pacakage) as well as documentation and feature set. Its a much better choice than building from scratch.

Besides, merely copying files to another disk is not a backup; its a RAID1 with very low latency.

[Gordon]

I second this motion. Implementing rdiff-backup is a good idea in terms of excito devtime (its a mature pacakage) as well as documentation and feature set. Its a much better choice than building from scratch.

Besides, merely copying files to another disk is not a backup; its a RAID1 with very low latency.

No real need to build from scratch. I've been using a weekly rotation scheme with rsync by creating a hardlink copy of yesterdays data and then rsyncing to today's copy of the data. In hindsight it would work just as good if you'd rsync to the same directory every day and then schedule a `rm -Rf; cp -al` on the directory where you want to keep today's mirror of the data at some time where you can be sure that the regular backup has completed, e.g. 1 hour prior to the next backup.

[Ubi]

yeah, but the point is you're a guru who can write his own scripts. I have my own implementation of differential backups with rsync as well. The point from the manufacturer is that they need an implementation that also works for noobs. In that respect, I agree that developing a front-end for rdif-backup, rather than a novel application, is a stable and rapid approach to address the issue.

[johannes]

HI guys, and yes, I don't disagree that rdiff would be nice, but more features = more settings = less usable. This _is_ a fact in my world, no matter how well you hide the knobs and buttons the users has to make choices he may not understand the consequence of (even as basic as ignoring the advanced-button), it messes with the comfort non-techy users need to feel. Plain rsync felt like a good first step, but we are listening, and if a majority would think plain sync is crap we'll do something about it when we can.

[Ubi]

This argument is, in my opinion, not really valid. There are many advanced switches to rsync that you are also not using. It is quite possible to make a frontend to rdiff-backup that is very simple, just like you did now for rsync itself. The difference is that it scales to advanced users (who are then required to SSH in), which the current solution does not. Also, again IMO, an rsync frontend may be an easier initial dev, but I really think a frontend to rdiff would pay for itself in reduced overhead for long-term maintenance and answering questions on fora to whiny users like me =)

[Gordon]

Allow me to whine then too.

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, since it lets you control how far back you want to be able to go to restore files and even create persistent copies. There's nothing real far fetched about this since simple date functions can provide you a number for the day of the week, day of the month, day of the year, week of the year, month of the year, and of course year itself. Using these numbers allows for simple choises that can be easily controlled by a web frontend, e.g. backup every day versus workdays (mo-fr) only, or create a persistent copy every first day of the month (bookkeepers love that sort of stuff).

Obviously you can also do this when using rdiff, but it more or less eliminates the need for the additional feature of the rdiff-backup-data directory. IMO the rdiff approach can be actually hazardous since it does not provide a way to group linked datafiles together (such as a MySQL database) and you most definitely do (should) not want to restore a single file in such a set.

[mike_nl]

Hi Johannes,

first:
Thank You for the update and yours and the teams work!

second:
Lucky we are rsync is now part of the base system.
I use rsync now a long time in gentoo and i am very happy with that.

third:
web interface for rsync, possible a third party team project?
Here are some links. If someone has an idea we all can work together
to build the web interface for the normal users to make it easier
to switch to rsync.
- http://www.debianhelp.co.uk/rsyncweb.htm
- http://www.debianadmin.com/rsync-backup ... tools.html
- http://blog.secaserver.com/2012/09/linu ... interface/

[mike_nl]

Update:

effevee:
the apache2 service did not restart automatically at the end, so the web UI became unresponsive. Had to login to the console to manually restart the service.

I had the same issue. Web interface stopped at 42%.
After restart the apache2 all runs fine without any issue.

Thank You again...