Reply to topic

Integrate an easy backup tool

243

Votes
246
3
User avatar Ujjwol
Registered Member
Posts
136
Karma
1
OS
Integrate a Backup and restore software like Time of Mac OS X....


Ujjwol, proud user of KDE 4 and member of KDE forums since 2008-Oct.
Image
Image
Regenwald
Registered Member
Posts
26
Karma
0
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! :)


Regenwald, proud to be a member of KDE forums since 2008-Oct.
User avatar hook
Registered Member
Posts
198
Karma
0
OS
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! :)


It's time to prod some serious buttock! ;)
Regenwald
Registered Member
Posts
26
Karma
0
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.


Regenwald, proud to be a member of KDE forums since 2008-Oct.
User avatar Primoz
Moderator
Posts
859
Karma
1
OS
And here's the link!


Primoz, proud to be a member of KDE forums since 2008-Nov.
flo
Registered Member
Posts
22
Karma
0
OS
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.
User avatar luckyb
Registered Member
Posts
1
Karma
0
OS
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 ;-)
User avatar mithras
Registered Member
Posts
31
Karma
0
OS
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, proud to be a member of KDE forums since 2008-Oct.
flo
Registered Member
Posts
22
Karma
0
OS
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.
User avatar mithras
Registered Member
Posts
31
Karma
0
OS
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, proud to be a member of KDE forums since 2008-Oct.
flo
Registered Member
Posts
22
Karma
0
OS
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.
User avatar TheBlackCat
Registered Member
Posts
2945
Karma
8
OS
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.


Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965
flo
Registered Member
Posts
22
Karma
0
OS
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).
Regenwald
Registered Member
Posts
26
Karma
0
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... :)


Regenwald, proud to be a member of KDE forums since 2008-Oct.
rabauke
Registered Member
Posts
17
Karma
0
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.

Last edited by Primoz on Thu Apr 02, 2009 10:30 pm, edited 1 time in total.

 
Reply to topic

Bookmarks



Who is online

Registered users: alra, Baidu [Spider], Bing [Bot], Drecker, Frousties, Google [Bot], ipwizard, JesusM, Kdesr, pulltheo, robgriff444, Section_8, Sogou [Bot], Theo, tymond, YaCy [Bot], Yahoo [Bot]