[tahoe-dev] backup error on root directory after upgrade

[Kyle Markley]

Developers,

After upgrading my grid to 1.8.0 I wanted to freshen my existing backup,
which was done with 1.7.1.  Everything seems okay until the very end of the
backup, when it's trying to update the root directory.

In this example I'm backing up a user named 'buildbot' (that happens to
run my tahoe buildbot).  Much appreciated if someone can tell me what's
going on here, and how I can fix it.


$ tahoe check buildbot:
Summary: Healthy
 storage index: ifue46nmpqpm73cljobrqgp7wi
 good-shares: 4 (encoding is 2-of-4)
 wrong-shares: 0


tahoe backup -v $HOME buildbot:
  <-----snip lots of output----->
 creating directory for '/home/buildbot'
Traceback (most recent call last):
  File "/usr/local/bin/tahoe", line 9, in <module>
    load_entry_point('allmydata-tahoe==1.8.0', 'console_scripts',
'tahoe')()
  File
"/usr/local/lib/python2.6/site-packages/allmydata/scripts/runner.py", line
118, in run
    rc = runner(sys.argv[1:], install_node_control=install_node_control)
  File
"/usr/local/lib/python2.6/site-packages/allmydata/scripts/runner.py", line
104, in runner
    rc = cli.dispatch[command](so)
  File "/usr/local/lib/python2.6/site-packages/allmydata/scripts/cli.py",
line 513, in backup
    rc = tahoe_backup.backup(options)
  File
"/usr/local/lib/python2.6/site-packages/allmydata/scripts/tahoe_backup.py",
line 324, in backup
    return bu.run()
  File
"/usr/local/lib/python2.6/site-packages/allmydata/scripts/tahoe_backup.py",
line 122, in run
    put_child(archives_url, now, new_backup_dircap)
  File
"/usr/local/lib/python2.6/site-packages/allmydata/scripts/tahoe_backup.py",
line 56, in put_child
    raise HTTPError("Error during put_child", resp)
allmydata.scripts.common_http.HTTPError: Error during put_child: 410 Gone
UnrecoverableFileError: the directory (or mutable file) could not be
retrieved, because there were insufficient good shares. This might indicate
that no servers were connected, insufficient servers were connected, the
URI was corrupt, or that shares have been lost due to server departure,
hard drive failure, or disk corruption. You should perform a filecheck on
this object to learn more.


$ tahoe check buildbot:
Summary: Healthy
 storage index: ifue46nmpqpm73cljobrqgp7wi
 good-shares: 4 (encoding is 2-of-4)
 wrong-shares: 0


$ tahoe check --raw --verify buildbot:                                    
     
{
 "results": {
  "needs-rebalancing": false, 
  "count-shares-expected": 4, 
  "healthy": true, 
  "count-unrecoverable-versions": 0, 
  "count-shares-needed": 2, 
  "sharemap": {
   "seq5-qphw-sh2": [
    "yuzbctlcuh7y3l3obmrxgf56qkczgrzq"
   ], 
   "seq5-qphw-sh3": [
    "juwmgssmwnhrhfdcpxxmrz3bghh37esx"
   ], 
   "seq5-qphw-sh0": [
    "47cslusczp3uu2kygodi3nlalcruscif", 
    "vjqcroalrgmft66mgiwfjug667fl6qjd"
   ], 
   "seq5-qphw-sh1": [
    "vjqcroalrgmft66mgiwfjug667fl6qjd"
   ]
  }, 
  "count-recoverable-versions": 1, 
  "servers-responding": [
   "juwmgssmwnhrhfdcpxxmrz3bghh37esx", 
   "vjqcroalrgmft66mgiwfjug667fl6qjd", 
   "yuzbctlcuh7y3l3obmrxgf56qkczgrzq", 
   "47cslusczp3uu2kygodi3nlalcruscif"
  ], 
  "count-good-share-hosts": 4, 
  "count-wrong-shares": 0, 
  "count-shares-good": 4, 
  "count-corrupt-shares": 0, 
  "list-corrupt-shares": [], 
  "recoverable": true
 }, 
 "storage-index": "ifue46nmpqpm73cljobrqgp7wi", 
 "summary": "Healthy"
}


-- 
Kyle Markley