[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [rdiff-backup-users] Safe to remove old increments while a backup ru

From: Thomas Harold
Subject: Re: [rdiff-backup-users] Safe to remove old increments while a backup runs?
Date: Wed, 26 Mar 2014 21:38:53 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

On 3/26/2014 7:04 PM, Sam's Lists wrote:
> Anyway, what should I do now? Is there an easy way to tell if my backup
> was corrupted?

You can use the rdiff-backup "--verify" option to test your latest
backup.  To test multiple increments, you have to do a bit of scripting.
 Or feed the dates one at a time into --verify-at arguments.


Here is a working fragment from our bash-based backup script.  It is
designed to verify the last 5 increments plus the 'now' increment after
the backup is run.  All of the $RDIFFBACKUP, $SED, $SORT, $GREP
variables are pointers to the various executables.  You will need to
customize this code to match your environment, but it shows how to parse
--list-increments and feed it back into a --verify-at command.

$OFFHOST is the FQDN of our backup server (or can be left blank to
backup to a local file system).  $OFFBASE is the full path to the backup
area, with a trailing '/' on it.  And $DIR is the directory within the
backup area being verified.


if [[ ! $VALIDATELASTN =~ ^[0-9]+$ ]]; then VALIDATELASTN=5; fi

    $RDIFFBACKUP --list-increments ${OFFHOST}::${OFFBASE}${DIR} | \
    $GREP -o 'increments\..*\.dir' | \
    $SED 's/^increments\.//g' | $SED 's/\.dir$//g' | \


echo "$RDIFFBACKUP verify last $VALIDATELASTN increments"

    echo "Verify backup at: ${INCREMENTTIME}"


    if [ $status -ne 0 ]; then
        echo "" >> $TMPFILE
        echo "$RDIFFBACKUP verify failed with status: $status"
        echo "$RDIFFBACKUP --verify-at "${INCREMENTTIME}"
${OFFHOST}::${OFFBASE}${DIR} failed with status: $status" >> $TMPFILE
        let ERRCNT+=1




Running --verify-at requires a lot of disk activity, especially as you
get deeper and deeper into the past.  This goes much faster if your /tmp
(or wherever you tell rdiff-backup to use as a temporary directory) is
on a different spindle then your backups, or is located on a SSD.

In order to verify a past increment, rdiff-backup has to reconstruct the
file.  The file system where your /tmp directory is located will need to
be large enough to hold the largest file being tested.  A safer rule of
thumb is a 2x or 3x multiplier.  I run into this issue when verifying
backups containing virtual machine images (which are ~30GB).  We were
blowing out the free space on our /tmp which was initially only a 16GB
file system.  We have since moved /tmp to it's own RAID array (RAID-1 on
a pair of Intel SSDs) and made it much larger.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]