243

Integrate a Backup and restore software like Time of Mac OS X....

well back in time also seems to be good. nice and clean look, very easy to use, doesn't have all that options that luckybackup has, it depends on what you need.
so more votes are welcome, we're already good!

Hmmm, I haven't heard about Back in Time yet, but it seems very nice for a standard user. A tighter integration with it in KDE would be very nice indeed!

someone told the author about this idea. he's honored and like to see lb in kde. you can find his whole statement in the commentar section of lb on kde-apps.

And here's the link!

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.