On 23/06/2017 11:46, Mike Fleetwood wrote:
On 23 June 2017 at 11:15, Ron Leach<ronle...@tesco.net> wrote:
rdiff-backup also seemed to make increments of all the other files in the
*other* directories under /srv/files. I didn't expect this - I had thought
that the example I used would e
List, good morning,
We use rdiff-backup to regularly backup our debian file-server, and we
wanted to additionally run a partial backup - into the same backup
directory - much more frequently for the more-volatile files (all the
files in our current projects). But when following the example
On 04/05/2017 06:39, Dominic Raferd wrote:
On 3 May 2017 at 22:28, Ron Leach<ronle...@tesco.net> wrote:
I'm assuming the script should be run from the
machine that initiates the backup - is that correct? Or should I be doing
this differently?
​The script needs to run l
On 02/05/2017 23:42, Dominic Raferd wrote:
I suggest you take a backup of the existing broken repository and then try
on it the latest version of my script which can be obtained from
http://www.timedicer.co.uk/programs/help/rdiff-backup-regress.sh.php.
Dominic, I fetched the latest script
On 02/05/2017 23:42, Dominic Raferd wrote:
I suggest you take a backup of the existing broken repository and then try
on it the latest version of my script
Dominic, thank you for this suggestion. And thank you for the script,
by the way, which I've used a few times before (on a different
On 02/05/2017 18:06, Yves Bellefeuille wrote:
But I must have done something wrong in the new set up. The first
attempt to check that mail backup would continue working failed with
Exception 'Found too many current_mirror incs!' raised of class
'':
Does this thread help?
On 02/05/2017 16:25, Ron Leach wrote:
We've just
replaced our mailstorage backup server with a new-build Debian system
equipped with bigger discs; the existing backup data has been copied
(rsync) into the same directory name but which is now mounted under
/srv. The mail system server remains
List, hello,
We have different machines for (i) our mail-server, and for (ii) a
backup of that mail server's mail storage. Under cron's control,
rdiff-backup uses a remote ssh login from the mail machine onto the
backup machine to make each backup of the mail store. We've just
replaced our
On 04/07/2015 18:10, Joe Steele wrote:
The [..] trace looks suspicious. The surrounding code
implies that the line would only be executed when there was no
previous backup found (and yet this was to be an incremental backup).
More specifically, no
On 04/07/2015 15:14, Remy Blank wrote:
Ron Leach wrote on 2015-07-04 16:08:
List, good afternoon, we're puzzled by this error (from our overnight
backup) because the backup destination has more than 350 GB free, and
the increment would likely have been somewhere between 50MB and 200MB
List, good afternoon, we're puzzled by this error (from our overnight
backup) because the backup destination has more than 350 GB free, and
the increment would likely have been somewhere between 50MB and 200MB.
It was a 'fatal' error, and the backup ceased there and then.
The nightly backup
List, good morning,
We're in the middle of moving our backup destination from an old
machine (with only 2TB) to a new one with 6TB space; each of these is
on a separate NFS share mounted under /mnt. Our migration scheme is
straightforward, but we hit a problem, possibly with permissions, and
On 15/04/2014 10:38, Claus-Justus Heine wrote:
Could it be that perhaps the UID mapping is not set up correctly? Being
able to do r/w but not being able to preserve times and set permission
could indicate that somehow the NFS-Server thinks that the files are
not owned by the user issuing the
On 12/01/2014 12:15, Chris Wilson wrote:
total != used+available because some blocks are reserved for use by
administrators (the root user) by the filesystem.
[snip]
The number of reserved blocks is:
* Old system: 1894289664 - 1874215424 - 20074240 = 0
* New system: 1922726712 - 1825057796 -
We're replacing our backup server and hit a problem moving our
existing backup directory to the new machine. Despite the new
machine's disk space being slightly larger than the space on the
existing system, we've run out of space on the new machine, and the
move is not yet complete. I think
On 16/12/2013 15:28, Dominic Raferd wrote:
Ron, see my utility here:
http://www.timedicer.co.uk/programs/help/rdiff-backup-regress.sh.php
Dominic, thank you for posting this. From its description, it would
seem to do exactly what we need.
I have not tried it. You'll think this odd,
16 matches
Mail list logo
