How to check validity of a backup

Asked by Doug Hutcheson

I am faced with being forced to update my Fedora 17 system, as F17 is going out of support.

I have been using deja-dup as my backup tool. It does not report success on completion and the only time I tried restoring my home directory on another machine, the attempt failed with an error (see below).

Before repaving my machine, I need to be sure I can recover my home directory and a few others.

How do I test that a backup is valid and can be restored?

The error on restore attempt was:
-------------------------------------------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1311, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1304, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1242, in main
    list_current(col_stats)
  File "/usr/bin/duplicity", line 546, in list_current
    for path in path_iter:
  File "/usr/lib/python2.7/site-packages/duplicity/diffdir.py", line 344, in combine_path_iters
    refresh_triple_list(triple_list)
  File "/usr/lib/python2.7/site-packages/duplicity/diffdir.py", line 330, in refresh_triple_list
    new_triple = get_triple(old_triple[1])
  File "/usr/lib/python2.7/site-packages/duplicity/diffdir.py", line 316, in get_triple
    path = path_iter_list[iter_index].next()
  File "/usr/lib/python2.7/site-packages/duplicity/diffdir.py", line 229, in sigtar2path_iter
    for tarinfo in tf:
  File "/usr/lib/python2.7/site-packages/duplicity/tarfile.py", line 1211, in next
    tarinfo = self.tarfile.next()
  File "/usr/lib/python2.7/site-packages/duplicity/tarfile.py", line 541, in next
    self.throwaway_until(self.next_chunk)
  File "/usr/lib/python2.7/site-packages/duplicity/tarfile.py", line 521, in throwaway_until
    self.fileobj.read(bufsize)
  File "/usr/lib/python2.7/gzip.py", line 243, in read
    self._read(readsize)
  File "/usr/lib/python2.7/gzip.py", line 290, in _read
    self._read_eof()
  File "/usr/lib/python2.7/gzip.py", line 329, in _read_eof
    hex(self.crc)))
IOError: CRC check failed 0x7ba711a7 != 0x192e7366L
-------------------------------------------------------------------------------------------------------

and the terminal from which I invoked deja-dup had the following information:
-------------------------------------------------------------------------------------------------------
** (deja-dup:4078): DEBUG: DuplicityInstance.vala:205: Running the following duplicity (4379) command: duplicity 'collection-status' '--gio' '--no-encryption' 'file:///media/Elements/Backups/Cardraeh/deja-dup-backups/FC17/FC17-full' '--verbosity=9' '--archive-dir=/root/.cache/deja-dup' '--log-file=/tmp/deja-dup-UTVFYW'

** (deja-dup:4078): DEBUG: DuplicityInstance.vala:559: duplicity (4379) exited with value 0

** (deja-dup:4078): WARNING **: Operation.vala:261: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files

** (deja-dup:4078): DEBUG: DuplicityInstance.vala:205: Running the following duplicity (4396) command: duplicity 'list-current-files' '--restore-time=2013-06-02T02:25:13Z' '--gio' '--no-encryption' 'file:///media/Elements/Backups/Cardraeh/deja-dup-backups/FC17/FC17-full' '--verbosity=9' '--archive-dir=/root/.cache/deja-dup' '--log-file=/tmp/deja-dup-TW8TYW'

** (deja-dup:4078): DEBUG: DuplicityInstance.vala:559: duplicity (4396) exited with value 30
-------------------------------------------------------------------------------------------------------

Question information

Language:
English Edit question
Status:
Answered
For:
Déjà Dup Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
Michael Terry (mterry) said :
#1

That is a funky error, I'm not sure I know what's causing that.

If you have any doubts about the backup, for which it seems you have reason, your best bet is to just do a direct copy of your data. Don't take any chances.

Revision history for this message
Doug Hutcheson (owlbrudder) said :
#2

OK - thanks. I will use another tool to do my backup this time, then repave my machine and see if deja works correctly. Glad I asked "8-)

Revision history for this message
Doug Hutcheson (owlbrudder) said :
#3

My backup target device was formatted NTFS. Would that cause deja-dup any grief? I know it upset rsync, as it was unable to apply some attributes to the archived files, until I reformatted the backup drive as ext3 and ran rsync again.

Revision history for this message
Michael Terry (mterry) said :
#4

No, NTFS shouldn't be a problem.

Can you help with this problem?

Provide an answer of your own, or ask Doug Hutcheson for more information if necessary.

To post a message you must log in.