243

It is very unfortunate but at the moment vfat is extremely important.
An external harddrive is only compatible in vfat mode, the sole file-system that is readable by Windows, MacOsX, Linux and all kind of devices.
Furthermore hard drives come preinstalled with vfat.

Removing vfat as requirement is like saying "we want our backup-tool only to work with Linux geeks".

I think the requirement that the files are directly browseable on the hd is much more discussable. (TimeMachine for instance does not have this feature). If there was a good KIO-slave then files could be easily browsed and would be secure from accidental modifications (thus killing a backup).

Might be it is possible to split files like with rar into 1.99GB files, so max size problem would be overcomed.

Also splitting would be useful if you have to move your collection using small USB drive

Lukas wrote:Might be it is possible to split files like with rar into 1.99GB files, so max size problem would be overcomed.

Also splitting would be useful if you have to move your collection using small USB drive

The problem of big files is only apparent when allowing direct access to the saved files. If the backup is stored in an opaque container (as for instance with DAR or TimeMachine) then the container size is usually not a problem.
So we have big files only if we want to allow access to big files on the backup-medium. There are several ways to deal with this:
- Replace the original file with a place-holder file and store the real file split as meta-information. One could, for instance, replace big videos with a (very) small one informing the user that the video has been successfully backuped, but can't be watched on the backup-medium.
- Leave access to the first 2/4gigabytes and store the remainder as meta-information. This gives access to the first parts of the files, but might confuse users (say a movie stops in the middle, etc.)
- Simply do not backup big files, and inform the user that she has to backup them differently

Again: this only happens if we leave users access to their backups through "normal" file-access. A safer way would be to implement (for instance) a "DAR" kio-slave and use DAR as backend. [Dar itself is not my personal favorite, for some other reasons, but it serves well in this example.]

So if it would use RAR format with 0 compression and spited content, everything would be accessible by by software and users directly (barely everyone has rar support). So basically problem is non-existing.

I would much prefer to maintain normal file access. The reason for this is that I don't need to have the backup software installed to restore the system.

Backups without compression and diffs??
Bad idea...

TheBlackCat wrote:I would much prefer to maintain normal file access. The reason for this is that I don't need to have the backup software installed to restore the system.

If you are forced to use vfat file system, anyway you wouldn't have ability to use it as normal file system. So rar solution is most capable one, as far as i've found yet.

What about NTFS?

Bump. Anyone working on this?

pembo13 wrote:

google01103 wrote:+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

Target vfat would be a waste of time. 2GB max file size. If the solution works on vfat, fine, but it shouldn't be a target.

Actually max size of a fat32 file is 4gb less 1 byte, the 2gb limit is from an old kernel (?) or maybe fat16 (?)

I am using back in time, and I was looking for a long time for a backup utility that would allow a full incremental system backup while allowing a full restore from a total crash, when none or minimum OS is present, somewhat like ghost.
that is in addition to all other important features mentioned above.

Hi all. No one has mentioned Krsync, which has been updated by the author for KDE4.

While it may not be the be-all-end-all of all the functionality requested in this thread, at least it's already available.

http://www.kde-apps.org/content/show.php/Krsync?content=68586

I'm the developer for TimeVault and I'm aiming at dead simple backups for KDE systems.

When it's ready, TimeVault will be a fully integrated KDE backup tool that is designed around external backups. It uses rdiff-backup and thus can backup to fat, ext3, ntfs, or pretty much anything else.

System Settings page and a progress update:
http://blog.chatonka.com/2009/12/timeva ... ss-update/

Very basic restore, more coming later:
http://blog.chatonka.com/2009/12/restor ... he-basics/

Project Homepage:
http://gitorious.org/timevault

-Andrew Stromme

astromme wrote:I'm the developer for TimeVault and I'm aiming at dead simple backups for KDE systems.

When it's ready, TimeVault will be a fully integrated

What's happened to TimeVault? It's not developed anymore?
It seemed really interesting, and we really needed something like it in our desktops!

timevault - very nice

However, why the limitation that it can only be used once an external drive is attached? For example, I have two hard disks in my desktop (no raid) and use backintime to keep things on both drives. Would this be possible with timevault?

It would of course also be cool if you had sftp integration or some such for external servers (might be there already, sorry, didn't check).

Oh, and thanks

2012 - A simple and powerful backup tool is still relevant and lacking in KDE SC. KDE SC should ship with an integrated tool like this.