243

I think those Kamion-ideas fit to the semantic desktop principe.
Does any body know kamion?

The User wrote:I think those Kamion-ideas fit to the semantic desktop principe.
Does any body know kamion?

Do you mean that kamion could also have a functionality to backup all files with a certain tag? That would indeed sound interesting, because it would allow the user to create his own recipes in a very easy way.

rabauke wrote:

The User wrote:I think those Kamion-ideas fit to the semantic desktop principe.
Does any body know kamion?

Do you mean that kamion could also have a functionality to backup all files with a certain tag? That would indeed sound interesting, because it would allow the user to create his own recipes in a very easy way.

Damn, that's the most genius idea I heard! :P

As far as I see, this is not an option yet. It's just plain text pointing to locations. I don't know if kamion supports KIO slaves, but if it's possible, this is really cool.

E.g. there is a kamion xml file which accepts the nepomuksearch kio slave. It is connected to the tag backup (e.g., this might be configurable). The user assigns some tags in dolphin. Each dir of file which must be backed up (besides mail and other files where the user don't know where they are located) is assigned with a tag. And kamion will do the rest. I think this is a good proposal for the kamion team.

I'm not sure which tool Kamion uses as backend. The kamion idea is pretty good, but it seems it's only good to do a single backup. Features like rdiff-backup (where only changes are recorded and where it's possible to delete some older backups) are not the purpose of kamion. Kamion is able to send the data by mail, but I don't want a daily backup from my homedir (25GB) mailed to my inbox

No doubt that kamion in its current state is not ready for the job. But I think it has the right approach and hence is a good starting point. It might be a good idea to define milestones and features in order to have a roadmap developers that are willing to work on this can follow.

The first milestone should include erverything needed to test the backup functionality, i.e. create/read system-wide and local "recipes" and do simple backup+restore.

Although recipes should be shipped with the applications, i.e. kmail should ship its recipe, this won't happen for the first milestones, so kamion needs some testing recipes. I think kmail and kontact in general are good targets for backups. Kamion currently lacks the option to have local recipes.

Maybe even GHNS can be used to download recipes from kde-apps.org. Once applications ship their own recipes, the latter will not be necessary though.

The second milestone would include the "killer-feature" of tag-backups, i.e. kamion would ask nepomuk for a list of tags the user has set and all the user has to do is tick the checkbox in-front of the tag whose files/folders he wants archived.

As a result the user would get two tabs:

Applications tab:
[x] Backup all of kmail
---[] data (emails)
---[] settings
[x] Backup all of korganizer
---[x] data (calendars)
---[x] settings
[] Backup all of amarok
---[] music files
---[x] collection database
---[x] playlists
---[x] settings
[] Backup all of konqueror
---[x] bookmarks
---[] history
---[x] settings

Tags tab:
[] A tag
[] B tag
[x] daily backup
[] holiday 2008
[x] project A
[x] project B

As you can see it would list all tags the user has defined, e.g. via dolphin, and the user just has to tick the ones that should be included in the backup.

Further it would need schemes, i.e. a daily backup includes a different combination of applications and tags than the "backup everything" scheme which might only be run once a month. The user can save combinations of tags and recipes and run them separately.

The third milestone would include advanced backup functionality, such as diffs and scheduling. So different schemes get run at different times automatically, including "sync backups" on shutdown etc.

The fourth milestone could include the functionality to let external applications trigger a backup, e.g. kmail telling kamion to use the kmail-backup.xml to perform a backup and where to save it to. Same for the other way around, if the user tells kmail to import an old backup, it should trigger kamion to process file xy and restore kmail's settings and emails from it.

Feel free to add your opinion to this, I think that we need a well structured plan to make this attractive to developers.

The biggest problem with Kamion is it isn't a true backup utility. It's primary goal (correct me if i'm wrong) is a migration tool. Therefore, it handles single backups pretty well. If you want to do backups more regularly, this might be a problem. The backups Kamion creates will be very large. Also smart backup removal, like this config option in BackInTime (http://backintime.le-web.org/img/backin ... remove.png) is not possible in Kamion.

So, combining these features will be really cool, but the roadmap you have written is missing one of the most important things. I wouldn't say the diff thing should be a third milestone. But it's up to the Kamion team to decide their direction: a migration tool (diff might become a feature) or a backup app (diff is really a must-have).

Oh, one more thing: if there's one program which might be a good choice to become *the* backup utility, I'll invest my time into it. I cannot write code (except php which I can handle quite well), but am able to assist in other things (more usability related). KDE has had its 4.2.2 milestone and is still not able to backup any file or directory. I think this should change asap .

Hi!
I'm working a Time Machine inspired backup for KDE. It's called Mabumbi. You can find more information on http://www.schwann.at/mabumbi
It uses storeBackup for the actual backup.
It is not yet in a state to be released in a first alpha (mainly because installation is not easy). I hope I can publish a first version this evening...

birdy wrote:Hi!
I'm working a Time Machine inspired backup for KDE. It's called Mabumbi. You can find more information on http://www.schwann.at/mabumbi
It uses storeBackup for the actual backup.

Hmmm, this actually looks pretty good as an idea — I really like that your Mabumbi is primarily intended for people who use an external (e.g. USB) disk for making backups :]

A backup tool is something I could really use. In the past I tried some, but gave up. Now I just zip from time to time some important directories. But it is not satisfying. Features I think are important (some mentioned already):
- access the files without the app
- incremental backups
- encryption support
- online-storage support (private server or some services which offer this).

Mark

markum wrote:A backup tool is something I could really use. In the past I tried some, but gave up. Now I just zip from time to time some important directories. But it is not satisfying. Features I think are important (some mentioned already):
- access the files without the app
- incremental backups
- encryption support
- online-storage support (private server or some services which offer this).

I'm repeating myself, but I really think that vfat support is much more important. Most backups go to external disks that have been formatted for fat32 and this is thus a real necessity.
Accessing the files without the app is a both nice and dangerous. Nice, for obvious reasons; dangerous because users could try to change the data there (maybe not even on purpose). Say for instance they click on the file, opening it in OpenOffice.org and then click on 'save'.

flo wrote:I'm repeating myself, but I really think that vfat support is much more important. Most backups go to external disks that have been formatted for fat32 and this is thus a real necessity.

I strongly agree with your point on this. If we already have good amount of data in the external disk (vfat), people cannot format it just to convert the file-system. So a backup utility should take care of all these limitations and provide a seemless backup/restore.

+1 for vfat (and ntfs) compatibility, iirc I had a problem with one of the existing utilities (flyback?) that was rsync based because I was backing up to a vfat external

I don't get it with vfat - it doesn't support rights and is therefore useless at best and positively dangerous at worst to use as a backup medium - I wouldn't touch it with a barge pole. Don't know about ntfs.

Imagine somebody backing their /etc/ or /var/ over to fat and restoring it. It would probably result in a non-functioning system. Whose fault is it? Why, the backup tool's of course!

Best is to get your gpartedCD out and partition your backup medium so that a proper file system takes care of your data and not one which was specifically designed for another OS and its requirements and is stone age on top of that, too.

My 2cs

toad wrote:I don't get it with vfat - it doesn't support rights and is therefore useless at best and positively dangerous at worst to use as a backup medium - I wouldn't touch it with a barge pole. Don't know about ntfs.

Imagine somebody backing their /etc/ or /var/ over to fat and restoring it. It would probably result in a non-functioning system. Whose fault is it? Why, the backup tool's of course!

Backup-solutions have two ways to deal with vfat external harddrives:
1. store meta-information separated from the files (see rdiff-backup).
2. store all the backuped data in a non human-readable format (see dar or Apple's time machine).

Best is to get your gpartedCD out and partition your backup medium so that a proper file system takes care of your data and not one which was specifically designed for another OS and its requirements and is stone age on top of that, too.

You really expect users to repartition their harddrives for backups?
A backup solution has to be dead-easy. Otherwise it won't be used (enough).

toad wrote:I don't get it with vfat - it doesn't support rights and is therefore useless at best and positively dangerous at worst to use as a backup medium - I wouldn't touch it with a barge pole. Don't know about ntfs.

Imagine somebody backing their /etc/ or /var/ over to fat and restoring it. It would probably result in a non-functioning system. Whose fault is it? Why, the backup tool's of course!

Best is to get your gpartedCD out and partition your backup medium so that a proper file system takes care of your data and not one which was specifically designed for another OS and its requirements and is stone age on top of that, too.

My 2cs

Re: vfat - 1) all/most backup medium is pre-formated to vfat 2) in a mixed environment one shouldn't assume Linux only file systems 3) In my case i was only backing up my personal data and ntfs write access at the time was pretty spotty (pre-ntfs-3g) 4) why would anyone backup /var 5) /etc is pretty much all text files so format of partition shouldn't matter

I think there are a lot of nice frontend ideas using - well - mediocre backends.
There should be a realy good backend, maybe integrated into Akonadi and Nepomuk, the frontends can easily play with.
Frontends are very individual, some people want to have something like time-machine, some want to have a simple konsole-tool, a Plasmoid or a KIO-slave.
But features like good filesystem support, small storage usage, crons, network filesystems or integration into other services acceptable for everyone. There are no pros and cons.
Frontends will come quickliy, first a konsole-tool, then a KIO-slave and then some more exciting graphical tools maybe using existing frontends.