243

luckybackup just has one important drawback: it uses rsync to copy data (that's what's written on their page), and rsync doesn't work if the other filesystem does not have the same features.
A common case is to backup important data to a vfat (fat32) external harddrive. vfat does not support permissions, etc. and therefore the backup will not be complete.
rdiff-backup (my current backup-tool) stores the lost information in meta-data files. Therefore one can still access the original files, and the removed information (permissions, ...) is backuped, too.
rdiff-backup is not perfect, though. Unless I'm wrong it does not support backuping 4GB+ files onto vfat systems. (It would need to split them).
Unfortunately this is a common scenario with virtual-machine disk-images.
Note that there once was (maybe still active) a fuse-mount for rdiff-backup data (called archfs). I only tried it once, and it failed, though.

I am not completely familiar with luckybackup and if I'm wrong please correct me.

Hello all,


the least I could do is join this forum and answer any question that arise, regarding the app I'm developing.
This way, people will find it easier to decide whether luckybackup is suitable for the job or not.

flo, you're right.
LB is based on rsync which does not support permissions transfer to a vfat partition (actually this is a vfat issue). Of course files will be tranfered normaly, but permisions will not.
Anyway, you just gave me a nice idea for my to-do list

For this idea to programs came up: Back in Time and LuckyBackup. It might a good idea to get the pros and cons of both programs listed and make a suggestion to improve one of them to be included into kde.
Both programs

• Both have backup and restore capabilities
• Both have filter options to exclude certain files
• Both are rsync based

luckyBackup

• Fully Qt4 based
• Interface is cluttered and difficult to understand for first time usage

Back in Time

• Much better interface for configuration
• Smart option to remove backups (like TimeMachine)

What I'd like to see is a KIO slave for one of these programs. All other kde programs could use the KIO slave to import a file from a backup long time ago.

Any other suggestions for pros and cons?

mithras wrote:For this idea to programs came up: Back in Time and LuckyBackup. It might a good idea to get the pros and cons of both programs listed and make a suggestion to improve one of them to be included into kde.

Both programs are "useless" if one can't backup his home on a vfat (fat32) external drive. That's the most common scenario and both fail at this task since they don't work around the fat32's limitations. For instance permissions are not copied, and fat32 does not allow the same charsets. Furthermore there are the issue with 4GB+ files that can't be copied onto fat32 (a common case with virtual machine or vmware disk images).
As long as the basic needed scenario is not supported I think neither of them is ready.
NB: this is not a rant on these tools. I actually hope that they will integrate these features so we can eventually integrate one of them.

flo wrote:Both programs are "useless" if one can't backup his home on a vfat (fat32) external drive. That's the most common scenario and both fail at this task since they don't work around the fat32's limitations. For instance permissions are not copied, and fat32 does not allow the same charsets. Furthermore there are the issue with 4GB+ files that can't be copied onto fat32 (a common case with virtual machine or vmware disk images).
As long as the basic needed scenario is not supported I think neither of them is ready.
NB: this is not a rant on these tools. I actually hope that they will integrate these features so we can eventually integrate one of them.

It's a silly answer, but the FAT issue is more a rsync and FAT problem than a problem with these tools. The 4GB files are a drawback from the FAT system itself, so these tools cannot be blamed.

For e.g. the permissions, that's a rsync problem. I'd be really cool to have a tool for rdiff-backup. At http://www.backupcentral.com/components ... iff-backup the differences between rsync and rdiff-backup are well listed. I'd choose rdiff-backup, but both Back in Time and LuckyBackup are using rsync. Maybe it's possible to create an app where you can choose which backup backend you want to use.

mithras wrote:It's a silly answer, but the FAT issue is more a rsync and FAT problem than a problem with these tools. The 4GB files are a drawback from the FAT system itself, so these tools cannot be blamed.

I agree completely: the problem is rsync here. But one can still blame the tools. After all they decide what backend they use.

For e.g. the permissions, that's a rsync problem. I'd be really cool to have a tool for rdiff-backup. At http://www.backupcentral.com/components ... iff-backup the differences between rsync and rdiff-backup are well listed. I'd choose rdiff-backup, but both Back in Time and LuckyBackup are using rsync. Maybe it's possible to create an app where you can choose which backup backend you want to use.

I'm using rdiff-backup for my backups too, and I think it would have been a better choice as backend. However, even rdiff-backup does not handle 4GB+ files.

flo wrote:I agree completely: the problem is rsync here. But one can still blame the tools. After all they decide what backend they use.

This has nothing to do with the backend, it has to do with the hard drive format. You can't put file larger than 4 gb on a fat32 hard drive no matter what backend you use, or even if you do it manually. It is a fundamental limitation of the hard drive partition format. If you want to do that you should use a different format for the hard drive. NTFS or EXT3 would both work on modern Linux systems and lack the 4 gb limitation.

TheBlackCat wrote:This has nothing to do with the backend, it has to do with the hard drive format. You can't put file larger than 4 gb on a fat32 hard drive no matter what backend you use, or even if you do it manually. It is a fundamental limitation of the hard drive partition format. If you want to do that you should use a different format for the hard drive. NTFS or EXT3 would both work on modern Linux systems and lack the 4 gb limitation.

Well they could use 'dar' as backend. Problem solved.
Don't forget, we are talking about backup-solutions and not synchronization.
Ideally rdiff-backup would split files that are too large (and keep track of them in its meta-data).

ok, i've picked up mithras's post (thanks for this overview) and the fat-arguments in my inital post! i'm thankful for new causes...

There is kamion ( http://kamion2.sourceforge.net/ ), which would need some changes, but IMHO provides the right approach to an integrated backup-tool.

http://sourceforge.net/mailarchive/foru ... ion2-devel

The idea is that applications ship an XML-file (http://lists.kde.org/?l=kde-edu&m=119386782518342&w=2 ) that defines filenames and variables (which contain the path to folders) that need backup. So e.g. kmail tells kamion which variable in its config file contains the path to the folder where the emails are stored and which files settings are stored in. Another example would be amarok telling kamion which path the user has set to contain the playlists.

This has the advantage that the user does not need to know where which kind of data is stored. Further, if an application changes its settings, e.g. the config-variable that defines the path to the folder where the emails are stored changes, the changed xml-file is installed with the new app version and no kamion developer has to keep track of everything.

There would be a system-wide and a userspace place where the "recipes" (xml files) are stored. The user could either start kamion, tick the apps and which of their data should be backed-up, where to save the backup to, set a schedule and start.

For amarok some people might want to backup their whole collection, others don't, so those would only tick "settings, playlists and database" and not "collection (music files)"

Another way could be that each application contains an import/export item in its file menu, which calls kamion with the xml-file set by the application.

I think that any backup application that needs the user to know where data and settings are stored cannot be called integrated.

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 .