I have a problem that a repository which 3 days ago occupied 26G has
mushroomed to 44G. The reason is that one night the backup seems to have
gone badly wrong, thinking the source data was missing, then the next
night it was all okay again - so it generated lots of diffs for files
that had gone
I'm writing because I need help getting my rdiff-backup process to
work reliably. I use rdiff-backup with cron, twice a day to snapshot
the entire ext3 rootfs of a desktop to an ext4 FS sitting atop
dmcrypt, iscsi, lvm, and raid. The full command I use is.
rdiff-backup \
--exclude-
Bram Schoenmakers wrote:
It's rather slow but, with only FTP access available, it's a pretty good
solution. Hope someone finds this useful.
The problem with mounting remote, virtual, file systems is that there's only
one rdiff-backup instance running: at the client. To compare a file, the wh
Op maandag 1 juni 2009 18:55:20 schreef Lorenzo Campanelli:
> Have any tips
> on troubleshooting this further?
What is the target file system?
--
Bram Schoenmakers
What is mind? No matter. What is matter? Never mind.
(Punch, 1855)
___
rdiff-backup-u
Op dinsdag 9 juni 2009 02:02:42 schreef Matt:
> Hi,
>
> I've recently been helping some friends backup data from a shared web
> host to which they only have FTP access. After some trial and quite a
> lot of errors, I've found that I can do this using curlftpfs (an FTP
> FUSE filesystem) as the sou
I have a problem when i tried to backup "directoriés" :
$>rdiff-backup.exe "directoriés" e2
i have a window-error-popup saying me that rdiff-backup is not a win32 valid
application
But if i tried to backup a directory called "directory" which contains a
subdirectory called "directoriés" or a fi
