Jump to content

False "error -34 (volume full)" error


Recommended Posts

Setup: Using Retrospect version 6.1.126, Driver Update 6.1.9.102 on PowerMac G5, OS X 10.4.9, all updates applied. Backing up local HD & several clients to attached FW drive.

 

This is a new install/setup of Retropsect on the Mac (just replaced the HD in the Mac), and it is the first running of the automated script I set up. From the log:

 

 

- 4/20/2007 1:00:27 AM:: Copying G5 New HD...

> Can't add that much data to backup set.

The limit is 976.6 T.

4/20/2007 1:13:51 AM: Execution incomplete.

Remaining: 314725 files, 2048.1 TB

Completed: 0 files, zero KB

Performance: 0.0 MB/minute

Duration: 00:13:24 (00:13:23 idle/loading/preparing)

 

 

First off, Retrospect is completely incorrect about the amount of data on "G5 New HD" - there is only about 35GB on the HD. (Where on earth is it getting this 2PB figure from?) And there is certainly under 100GB on all the clients - but it hasn't even gotten to them.

 

How do I work around this bug?

 

I have run tests on the FW drive and internal HD (Disk Utility, TechTool Pro 4.5.2) and they check out ok.

 

Thanks for any info here.

Link to comment
Share on other sites

Quote:

How do I work around this bug?

 


 

It's not clear yet that this is a bug. In my experience, we have only run across this error when there has been directory corruption on the source volume. Given that your first backup of this volume is (presumably) the first time you've seen this error, it certainly suggests a problem with the volume.

 

Quote:

I have run tests on the FW drive and internal HD (Disk Utility, TechTool Pro 4.5.2) and they check out ok.

 


 

Assuming you booted from the CD-ROM or your external FW drive when you performed the tests, I'm surprised. If you can get your hands on a copy of DiskWarrior, I'd also try that.

 

You might try scanning the volume in Retrospect in Configure> Volumes> Browse. I'm not sure that you will even get through the scanning process, but if you do, try viewing the volume using the view option "Sorted files, no folders," performing the sort by size. It may be that you'll see a single file with an impossible size. You could then configure a backup to exclude only that file and see if it runs OK.

 

If it does, I'd then suggest reformatting the drive (using HFS+) and restoring the files from your just-performed backup. (If you have the capacity, I'd perform a second backup before the reformat/restore. I always like to have at least two copies of a backup, "just in case.")

 

If you aren't able to back up the local volume, you might see if you can run your backups on the client volumes to confirm that there isn't something wacky with Retrospect's config file. The easiest way to try this would be to duplicate your backup script and then delete the local source volume.

 

Let us know what you try and how it works.

Link to comment
Share on other sites

  • 3 weeks later...

To close up this issue, the problem was indeed a mystery file which was many GB large. I was not present at the Mac when it was discovered to see the details of this mystery file, but deleting that through Retrospect solved the problem. Thanks for the pointer.

 

I still believe this "error," that Retrospect thinks there is more data to be copied than there actually is, is a bug. The Finder reports correct values (as well as Disk Utility & TTP), so Retrospect should too. That is, unless EMC believes there to be a bug in the Finder or whatever APIs they are using to collect this file information.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...