Shirt Pocket Discussions

Shirt Pocket Discussions (https://www.shirt-pocket.com/forums/index.php)
-   General (https://www.shirt-pocket.com/forums/forumdisplay.php?f=6)
-   -   Smart Update Failed - Device Full (https://www.shirt-pocket.com/forums/showthread.php?t=1556)

ae6dx 08-20-2006 11:14 PM

Smart Update Failed - Device Full
 
Source HD has 28.81 GB used. Target HD has 37.2 space total. Yet the target is full. Using smart update. Why would this be? If the target has m,ore space than source why is it filling up?

See log below
| 06:43:14 PM | Info | SuperDuper!, 2.1.3 (80), path: /Applications/SuperDuper!.app, Mac OS 10.4.7 build 8J135 (ppc)
| 06:43:14 PM | Info | Started on Sun, Aug 20, 2006 at 6:43 PM
| 06:43:14 PM | Info | Source Drive: Macintosh HD, mount: /, device: TOSHIBA MK6021GAS, interconnect: Internal ATA, file system: "Journaled HFS+", OS: 10.4.7 (8J135), capacity: 55.76 GB, used: 28.81 GB, directories: 74564, files: 327102, ejectable: NO, ACLs: Disabled
| 06:43:14 PM | Info | Target Drive: OS Backup, mount: /Volumes/OS Backup, device: SmartDis FireLite Drive, interconnect: External FireWire, file system: "Journaled HFS+", OS: 10.4.6 (8I127), capacity: 37.20 GB, used: 25.33 GB, directories: 60856, files: 287488, ejectable: NO, ACLs: Disabled
| 06:43:14 PM | Info | Copy Mode : Smart Update
| 06:43:14 PM | Info | Copy Script : Backup - all files.dset
| 06:43:14 PM | Info | Transcript : BuildTranscript.plist
| 06:43:15 PM | Info | PHASE: 1. Prepare to Copy Files
| 06:43:15 PM | Info | ...ACTION: Preparing Macintosh HD
| 06:43:15 PM | Info | ......COMMAND => Verifying the integrity of volinfo.database
| 06:43:16 PM | Info | volinfo.database OK
| 06:43:16 PM | Info | ......COMMAND => Enabling permissions on Macintosh HD
| 06:43:16 PM | Info | Refreshing Disk Arbitration ...
| 06:43:17 PM | Info | ......COMMAND => Verifying that permissions are enabled for Macintosh HD
| 06:43:17 PM | Info | Permissions on '/' are enabled.
| 06:43:17 PM | Info | ...ACTION: Repairing permissions on Macintosh HD
| 06:43:17 PM | Info | ......COMMAND => Repairing permissions on Macintosh HD
| 06:43:31 PM | Info | parent directory ./Users/Shared/SC Info does not exist
| 06:44:40 PM | Info | Started verify/repair permissions on disk disk0s10 Macintosh HD
| 06:44:40 PM | Info | Determining correct file permissions.
| 06:44:40 PM | Info | The privileges have been verified or repaired on the selected volume
| 06:44:40 PM | Info | Verify/repair finished permissions on disk disk0s10 Macintosh HD
| 06:44:40 PM | Info | ...ACTION: Preparing OS Backup
| 06:44:40 PM | Info | ......COMMAND => Enabling permissions on OS Backup
| 06:44:40 PM | Info | Refreshing Disk Arbitration ...
| 06:44:41 PM | Info | ......COMMAND => Verifying that permissions are enabled for OS Backup
| 06:44:41 PM | Info | Permissions on '/Volumes/OS Backup' are enabled.
| 06:44:41 PM | Info | ......COMMAND => Verifying that OS Backup ACL support matches Macintosh HD
| 06:44:41 PM | Info | ...ACTION: Preserving Spotlight state on OS Backup
| 06:44:41 PM | Info | ......COMMAND => Disabling Spotlight search indexing on OS Backup
| 06:44:41 PM | Info | PHASE: 2. Copy Files
| 06:44:41 PM | Info | ...ACTION: Copying files from Macintosh HD to OS Backup using Smart Update
| 06:44:41 PM | Info | ......COMMAND => Cloning Macintosh HD to OS Backup
| 06:44:42 PM | Info | Copying copy files with delete using script: /Users/bradford/Library/Application Support/SuperDuper!/Copy Scripts/Standard Scripts/Backup - all files.dset
| 06:44:43 PM | Info | Loading 19 commands from copy script /Applications/SuperDuper!.app/Contents/Resources/Copy Scripts/Exclude system temporary files.dset
| 06:44:43 PM | Info | Loading 6 commands from copy script /Applications/SuperDuper!.app/Contents/Resources/Copy Scripts/Exclude system cache files.dset
| 06:44:43 PM | Info | Loading 1 commands from copy script /Applications/SuperDuper!.app/Contents/Resources/Copy Scripts/Exclude Norton FileSaver files.dset
| 06:44:43 PM | Info | Loading 2 commands from copy script /Applications/SuperDuper!.app/Contents/Resources/Copy Scripts/Exclude Spotlight search index.dset
| 06:44:43 PM | Info | Loading 0 commands from copy script /Users/bradford/Library/Application Support/SuperDuper!/Copy Scripts/Standard Scripts/Backup - all files.dset
| 06:44:43 PM | Info | /
| 06:44:46 PM | Info | /dev
| 06:44:46 PM | Info | /.Spotlight-V100
| 06:44:46 PM | Info | Ignoring /.Spotlight-V100/.journalHistoryLog
| 06:44:46 PM | Info | Ignoring /.Spotlight-V100/.store.db
| 06:44:46 PM | Info | Ignoring /.Spotlight-V100/_rules.plist
| 06:44:46 PM | Info | Ignoring /.Spotlight-V100/ContentIndex.db
| 06:44:46 PM | Info | Ignoring /.Spotlight-V100/store.db
| 06:44:46 PM | Info | /Network
| 06:44:46 PM | Info | /private
| 06:44:46 PM | Info | Did not COPY shared-item /private/tftpboot/private/tftpboot because it would have overwritten the original
| 06:44:46 PM | Info | Ignoring /private/var/db/volinfo.database
| 06:44:46 PM | Info | Ignoring /private/var/db/BootCache.playlist
| 06:44:52 PM | Info | Ignoring /private/var/run
| 06:44:52 PM | Info | Ignoring /private/var/tmp/ismp001
| 06:44:52 PM | Info | Ignoring /private/var/tmp/mds
| 06:44:52 PM | Info | Ignoring /private/var/tmp/com.netopia.timbuktu.pro.skype.501
| 06:44:52 PM | Info | Ignoring /private/var/tmp/com.netopia.timbuktu.pro.skype.0
| 06:44:52 PM | Info | Ignoring /private/var/tmp/folders.501
| 06:44:52 PM | Info | Ignoring /private/var/tmp/console.log
| 06:44:52 PM | Info | Ignoring /private/var/tmp/com.apple.speech.synthesis.globals
| 06:44:52 PM | Info | Ignoring /private/var/vm
| 06:44:52 PM | Info | /sbin
| 06:44:55 PM | Info | /sw
| 06:45:10 PM | Info | /System
| 06:48:27 PM | Info | Ignoring /System/Library/Extensions.kextcache
| 06:48:27 PM | Info | /.Trashes
| 06:48:27 PM | Info | /TheVolumeSettingsFolder
| 06:48:27 PM | Info | /cores
| 06:48:27 PM | Info | /Users
| 06:50:59 PM | Info | /usr
| 06:51:52 PM | Info | /.vol
| 06:51:52 PM | Info | Ignoring /.vol
| 06:51:52 PM | Info | /Volumes
| 06:51:52 PM | Info | Ignoring /Volumes/BACKUP#1
| 06:51:55 PM | Info | Ignoring /Volumes/FIRE
| 06:51:55 PM | Info | Ignoring /Volumes/OS Backup
| 06:51:55 PM | Info | Ignoring /Volumes/Macintosh HD
| 06:51:55 PM | Info | /Library
| 07:01:18 PM | Info | /Applications
| 07:28:56 PM | Info | WARNING: Caught I/O exception(28): No space left on device
| 07:28:56 PM | Info | WARNING: Source: /Applications/Compressor.app/Contents/Resources/French.lproj/AboutNFR.tif, lstat(): 0
| 07:28:56 PM | Info | WARNING: Target: /Volumes/OS Backup/Applications/Compressor.app/Contents/Resources/French.lproj/AboutNFR.tif, lstat(): 0
| 07:28:56 PM | Info | Attempting to copy file using copyfile().
| 07:28:56 PM | Info | Attempting to copy file using ditto.
| 07:28:57 PM | Error | ditto: /Volumes/OS Backup/Applications/Compressor.app/Contents/Resources/French.lproj/AboutNFR.tif: No space left on device

dnanian 08-21-2006 09:20 AM

Hi, Brad. I've already replied to your support mail, so let me refer you there. (For others, see the Troubleshooting section of the User's Guide for a full discussion of how this happens with Smart Update.)

Twitch 08-24-2006 05:46 PM

I also get this error. Working with video, my files tend to be quite large and they do get moved around. I usually get this error 50-70% of the time I try to mirror two drives of identical size.

There are so many things I love about this program, unfortunately I'm getting tired of comming in to my studio in the morning to find superduper failed to mirror my drive the night before.

Any chance this can be improved in a future release? I used to use psync to mirror my drives from the command line and I don't recall this ever happening.

dnanian 08-24-2006 05:50 PM

We're looking at various ways to improve this in the future, Twitch, yes.

psync didn't have this problem for you because it first runs an erase pass, then it does a copy. The problem with that is it leaves you a lot more vulnerable -- if your drive failed in between, you'd lose both the "backed up" copy and the original, since everything had been deleted...

Twitch 08-25-2006 06:30 PM

ahhh.. I didn't look at it from a vulnerability aspect, makes sense. I guess psync exposes files renamed or moved to potential data loss.

Now I'm a bit more nervous about the suggested work around (erase then copy). This potentialy leaves the entire drive vulnerable for data loss.

I guess this is a no-win situation. I suppose it's best to have a backup drive larger than the orignal for maximum safety and in that case it's good to know SuperDuper will keep the data as safe as possible during the copy operation.

dnanian 08-25-2006 07:28 PM

Alternative workarounds are simply "helping" Smart Update. So, if you've renamed a large folder on the source, do the same on the destination. Then, SD! won't have trouble.

But, as I said, we have some ideas... :)

SidneySM 09-15-2006 11:24 PM

Here's an idea: Run a prep pass in which files to be deleted, added, and updated are determined, then update the backup, beginning with deletion.

dnanian 09-16-2006 10:03 AM

No. That's the obvious thing to do (two pass), but it's also the wrong thing to do, because if you delete first and then can't copy, you've lost data (especially with a move or rename).

SidneySM 10-14-2006 06:25 PM

Quote:

Originally Posted by dnanian (Post 8471)
No. That's the obvious thing to do (two pass), but it's also the wrong thing to do, because if you delete first and then can't copy, you've lost data (especially with a move or rename).

Sorry this is so delayed, but...

OK, I missed the move/rename thing. I had always assumed that SD! used some kinda checksum to do the smart update rather then just checking path. I mentioned a scan pass so that the delete pass would only delete files that no longer existed on the source drive.

Guess I'll have to wait for those ideas you have to be realized ;)

dnanian 10-14-2006 07:41 PM

Consider how slow it would be to checksum each destination file and try to match it against every source file, Sidney...

jmooers 10-24-2006 10:47 AM

This seems to be a huge limitation of SuperDuper!. We have been using it on our local system, and it worked so great that I installed it on our server.

I have this same problem, but for some reason it only happens every 5-7 days. It is as if the program does not let go of the virtual memory so the disk eventually fills.

I switched from Retrospect to SuperDuper! because I was constantly having to babysit Retrospect, making sure it did back up and did so correctly. I feel like now, I have to login to the server every morning to make sure it backed up, and reexecute an Erase disk if it is full. Who has time to do that? It is disappointing.

I find that 2 MAJOR features missing with this app.
1. This problem
2. The lack of integrated email notification

Other than these 2 issues, I love the program. I hope that future upgrades hold these features. :)

dnanian 10-24-2006 11:19 AM

This has nothing to do with memory, jmooers: it's because files are being actively updated on the source volume when we try to copy them. If you look at the name of the file that seems to be filling the drive, that's what's causing issues.

If this is a server, it's possible that it's a log or similar -- and you can adjust the copy scripts to ignore the log folder(s).

If you have a lot of active services during copy, it's possible those are the problem -- and you should use the before/after copy shell script call-outs to disable and re-enable those services during the backup.

As far as email notification goes, Growl works quite well, so I'd suggest giving that a shot.

Hope that helps.

s_dup 03-14-2007 12:15 PM

Quote:

No. That's the obvious thing to do (two pass), but it's also the wrong thing to do, because if you delete first and then can't copy, you've lost data (especially with a move or rename).
But why wouldn't this work safely if the source drive has items that should no longer be on the destination drive. For example if you delete folders on the source drive and clone the drive the same folders will be deleted on the destination drive. Can't you have a option that allows deletes to proceed copies (freeing up space). Even if the rest of the cloning fails you were still going to delete the file on the destination drive anyway, yu haven't lost anything you were giong to loose anyway. You're just doing it first. It fact it might help you save data... if you forget to check the log you might assume the backup worked when it failed. It might have a small speed advatange as well by freeing up space so the other copies go faster. But most important it means th user doesn't have to worry about cloning failing if low on disk space or working wih large files.

dnanian 03-14-2007 12:48 PM

Not necessarily, no. Consider a "move" of data from one location to another. If we delete the "old" copy first and the new copy is damaged, you lose files...

s_dup 03-14-2007 01:59 PM

But if you scanned the entire disk directory at the beginning wouldn't you be able to determine what has only moved and what was actually deleted? Don't you have to make that determination at some point? You might even be able to post an estimated time to complete backup (e.g 23 file to copy, estimated time is 5.5 minutes).


All times are GMT -4. The time now is 06:18 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2024, vBulletin Solutions, Inc.