Most likely this is an allocation block size issue. Retrospect 4.1 fixed
most of these problems, but depending on the number of files you have to
restore, you may still see this "really overflow..." problem occasionally.
See Dantz Tech Note 412 at
for more on how Retrospect calculates the size of files.
Keep in mind that even though Retrospect says you will overflow the
destination volume, it will still allow you to do the full restore--the
two-part method shouldn't be necessary. If you really don't have enough disk
space, Retrospect will stop with an error when it runs out of room.
Technical Support Specialist
Dantz Development Corporation
> From: Michael Gaines <[EMAIL PROTECTED]>
> Reply-To: "retro-talk" <[EMAIL PROTECTED]>
> Date: Fri, 4 Aug 2000 16:07:00 -0500
> To: [EMAIL PROTECTED]
> Subject: Strange behavior when restoring to entire disk
> I've encountered the following behavior on several occasions in the
> past and just wondering what might be going on. Since I'm able to
> work around the problem it's not critical, just more of an observed
> Yesterday one of my users managed to trash her Mac's boot partition
> sufficiently that diagnostic tools weren't having a lot of luck. I
> decided that I would just restore the drive from a backup made
> earlier in the week.
> To prepare, I booted from an external hard drive with a copy of
> Retrospect Client (4.2A) installed, verified that the partition was
> HFS+ and 1024MB in size then erased the partition using the Finder's
> Erase Disk command (set to HFS+ format).
> From the Retrospect Server I set up to do an immediate restore to
> entire disk to the newly erased partition. However, after Retrospect
> went through the process of identifying the files that needed to be
> restored, it told me that the 1.22GB of files was 196MB too much.
> Having encountered this problem before, I manually unselected enough
> items to get below the "limit" then proceeded with the restore. Once
> that was done, I went through the restore to entire disk process
> again. This time after identifying the files that needed to still be
> restored (basically the ones that I unselected on the first pass), it
> said that the disk would have 4M free after restoring. After
> restoring those files, all files that were part of that particular
> snapshot had been successfully restored to the partition. Just to be
> sure, I went through the restore to entire disk one more time. When
> it got to the file identification stage, Retrospect indicated that no
> additional files to be restored since all the files were already on
> the destination partition. After the final restore, the amount of
> data on the partition was less than 850MB.
> My question is why is Retrospect incorrectly reporting/calculating
> the space requirement of the data during the restore process? It
> appeared to correctly calculate the amount of data (~840MB) when I
> did a test backup of the newly restored partition.
> The Server is a PowerMac G3 b&w, 128MB RAM, Mac OS 9.0.4, Retrospect
> 4.2. The client is a PowerMac G3 beige, 192MB RAM, Mac OS 8.5.1,
> Client 4.2A. Back up was to a DLT4000 drive.
> I've had this happen to me on other occasions involving other
> PowerMacs, earlier versions of Retrospect (4.0 and 4.1 if memory
> servers), and/or while doing local backups to a Mac file set. In
> almost all cases I could work around the problem by doing multi-pass
> restores, or in one case restoring to a larger drive then using
> Retrospect to duplicate the restore data to the proper drive.
> Michael Gaines snail mail: Learning Technology Center
> Computer Systems Administrator Box 45, GPC
> Nashville, TN 37203
> mailto:[EMAIL PROTECTED] (615) 322-2480
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives: <http://list.working-dogs.com/lists/retro-talk/>
> Problems?: [EMAIL PROTECTED]
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]