[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rdiff-backup-users] New GUI for rdiff-backup: JBackpack
From: |
Ronny Standtke |
Subject: |
Re: [rdiff-backup-users] New GUI for rdiff-backup: JBackpack |
Date: |
Fri, 15 Oct 2010 10:28:45 +0200 |
User-agent: |
KMail/1.13.5 (Linux/2.6.35-22-generic; KDE/4.5.2; i686; ; ) |
> Mmmm...what can I say....
> IT'S COOL!!!!!!!!!!!!!!
> Realy a grat job!!
> My best compliment.
I'm glad to hear that! ;-)
> I wonder only about smb. Does rdiff-backup work fine with it?
We tested it successfully with a QNAP NAS:
http://www.qnap.com/pro_detail_feature.asp?p_id=136
(Unfortunately, these NAS solutions provide SSH access only for the root
account, therefore we added SMB support in JBackpack so that it can be used as
the backup destination for normal users.)
After several months we run once into a situation with a filesystem error: a
diff file could not be deleted, even after rebooting the client and remounting
the SMB file system, only restarting the NAS helped. Besides this single
problem, SMB works fine so far.
> ...By using smbfs or CIFS, the complete file is transferred over the
> network.
Yes, just using an SMB mountpoint is much slower than having a cooperating
backup destination (with ssh access and a remote rdiff-backup instance)
because generating the diffs then means downloading the latest mirror file
from your NAS and comparing it with the current local file and then uploading
the diff.
I really hope that one day rdiff-backup will be able to cache the file
checksums at the backup destination so that only checksums have to be
downloaded instead of complete mirror files when generating diffs. Aren't
there alredy some patches for rsync that enable caching of the checksums?
Best regards
Ronny