Jump to content

wp1

Members
  • Content count

    33
  • Joined

  • Last visited

Everything posted by wp1

  1. wp1

    Problem with ZFS

    I am encountering a related issue - I'm trying to use a ZFS disk to hold a media set, rather than to back up the ZFS volume. ZFS seems like a perfect destination file system for a Retrospect media set. But Retrospect 11 won't see the volume at all. If I try to create it there by explicitly specifying a path, I just get back "An error has occurred". Running OS X 10.9.4 and OpenZFS 1.30.
  2. That stop/start button has been there for a long time. That's not RetroISA, but the main Retrospect engine. I can't tell if you're being sarcastic, or actually happy about the decrease in CPU usage. A decrease from 110% to 75% is certainly a significant improvement, but it isn't anything to shout about considering the RetroISA daemon runs all the time. A decrease to well under 1% (all the time) would be more what I would expect from a background daemon monitoring fsevents. Do you see Apple using that much to track changes for Time Machine?
  3. I tried Retroclient 6.5.136 on both Windows 2000 (I think WIn2000 isn't supported by v10 Retrospect), and Windows 2003. I also tried Retroclient 7.7.114 on Windows 2003, with the same result.
  4. RetroISA is slightly better than before, but only slightly. On my Mac Pro, after 24 hours it spends about 2/3 of the time eating 30-60% of a CPU and 1/3 idled to a bit less than 1%. On my mini, which only has two cores, it is far worse - close to 95% of the time RetroISA is eating 30-70% of a CPU. The short time it is idled, it is still eating 5-10%, sometimes. I can provide "top" samples, but didn't want to paste 1000 lines here. I'll be disabling RetroISA again. How is it possible to eat so much CPU just processing file system events? Time Machine certainly doesn't have this issue. Also not fixed is communication with Windows 6.5.136 clients. It communicates with the client, but doesn't show any disks. This worked with Retrospect 9, but was broken at 10.0 and is still broken with 10.1. 10.0 release notes show this client version as supported. I did call this in to support, but no answers beyond a should shrug. If you disabled RetroISA with "launchctl unload -w ....", you have to re-enable it with "launchctl load -w ..." or the client installer will abort with no intelligible error (install log shows postinstall failed). I disabled it this way because changing the .ini file as documented didn't work.
  5. > But did running that duplicate harm the source Snow Leopard system disk? Yes, it does. The statement that Retrospect 6 does not modify the source disk is inaccurate. Backing up (and I suppose duplicating) under Snow Leopard with Retrospect 6 results in two nasty problems: 1. It causes all HFS compressed files to be uncompressed as it reads them. 2. It sets the "last modified" date of all HFS compressed files to the time that file was touched by Retrospect.
  6. The current Snow Leopard compatibility statement for 8.1.622 says it is 10.6 compatible, but then later says there are major known problems. The UI script options bug, and that compressed system files are reloaded uncompressed I would consider major bugs. I've also found a number of posts as recent as a couple of weeks ago complaining of constant crashes under 10.6 and documenting problems with Retro Client backup of Snow Leopard systems. I didn't see any mention of build numbers in these posts. Yet, in the release notes for 622, it has as fixed: 21548: Snow Leopard: Scripts: No options displaying Build 626 release notes say this is fixed: 23640: Can't backup or restore of 10.6.1 large compressed files properly The current statement is KB 9723 and is dated 10/12/2009. Is there a current, accurate, Snow Leopard compatibility statement? What exactly is the state of 10.6 compatibility as of build 626?
  7. Thanks for the tip on that. I didn't know about that one.
  8. I did complete a full system (OS) restore with build 626. It appears to be intact. Files were properly restored with HFS compression. There is a problem with rsync that when you specify -E, it wants to flag some files that don't differ, so I couldn't get a 100% verification using rsync. For example, if you rsync such a file, then run rsync again, it will transfer it a second time, and third, and.... The rsync issue looks like it may be some how tied to the quarantine extended attribute. But, a spot check of the files flagged by "rsync -n" showed them to be ok.
  9. That's how I would interpret it too, except the heading says "when running a supported Retrospect configuration". The first statement in the article is that Snow Leopard is only supported with build 622 and above, so if you were running prior to 622 then you wouldn't be running a supported configuration. If you're running a supported configuration, then it must be build 622 and above, so the items below that would apply to 622 and above.
  10. My dad recently upgraded to Snow Leopard. Not knowing Retrospect 6.1 wasn't compatible with 10.6 (I didn't know either), he did a back up. There were hundreds of thousands of compare errors, all modification time mismatches. It appears Retrospect updated the last modification time of virtually every system file (but not those in the home directory). I assume this affected any compressed system file. Yes, I realize (now) that 6.1 is officially incompatible with Snow Leopard. The question is what did Retrospect do to all of the files? Did it just erroneously update the last modification time, or did the backup uncompress every file?
  11. Yes, I've been aware since it happened that Dantz was acquired by EMC. Freudian slip. I've been using Retrospect for 20 years. It's still Dantz to me, and even the forums are still forums.dantz.com. Sorry for the misstatement. You are right, I don't interpret "unsupported" to mean "totally broken". If a software product will damage your system by doing something that should be read-only, I expect that to be an explicitly stated warning. Perhaps they didn't know, but I find that hard to believe. There are innumerable unsupported applications that aren't even close to totally broken, or not even broken at all. And, there are very, very few that will trash your system doing something that should be read-only. But I don't want to get in to an argument over semantics. Going back to the original question, some additional research confirms that the last modification time was updated on every (HFS compressed) system file because Retrospect 6.1 caused them to be uncompressed when backing them up. I don't even know how you do that accidentally. It normally takes an explicit request to do that, like running afscexpand.
  12. > Lots of things would be nice, including world peace and a Retrospect 8 manual. Yeah, but is it really asking too much for someone to take 5 minutes and update the Compatibility Statement to be accurate? And maybe put a big red warning on the Retrospect for Mac page "EVEN DOING A BACKUP OF SNOW LEOPARD USING 6.1 WILL IRREPARABLY DAMAGE YOUR SYSTEM"? I can't argue with your list of limitations. But I've poked at a few other backup solutions, and haven't found one that works as well as Retrospect for full/incremental/remote backups. 6.1 worked well for me, and performance on Intel was about as good as v8 until this recent release which seems to have improved performance. I guess on the manual, they figure "We're Mac users. We don't need no stinkin' manual!" Regarding scripting, I haven't tried to do that yet. Are you referring to built-in sripting, or does that mean it also can't be scripted with Applescript or Automator? Not being able to read older backups on v8 is a huge problem, especially considering you can't run Retrospect 6.1 on Snow Leopard. I run two TM drives, one of which is a RAID 0, and have a perl script that switches between them each hour. But I've been using Retrospect for my longer term backups (until now). Now those long term backups are useless. You did leave off one issue - pricing. Maybe this doesn't affect a lot of people, but I use Workgroup at home, which includes 20 client licenses. Upgrading to the equivalent in V8 is ridiculously priced for me. My option is to buy the regular version and add client packs, but that gives up features I had.
  13. Thanks for the response. Have you done any restores yet to verify your backups get restored properly, especially a full system restore? The compatibility statement in the article you referenced is the one I had seen already. It's dated 10/12/2009, before the current release. The first line there says 622 is Snow Leopard compatible. But, if you go down to the section (not bolded) that starts off "Keeping the above changes in mind when running a supported Retrospect configuration", it says the scripting UI and compression problems are still there. Since it says "running a supported..." that section would seem to mean at least build 622 on Snow Leopard. Under Leopard, back in September, I tried V8 and had 2 pages of bugs and other issues with just one sitting. Last night I installed v8 build 626. This build is *much* better. I don't seem to be encountering the UI bug listed in the compatibility statement. I did a backup of a system volume and am in the process of restoring now. Spot checking files with hfsdebug, it is properly restoring files compressed. I'm waiting for the restore to complete to compare the source and destination volume sizes. Perhaps an rsync could be used to verify the integrity of the restore. It sure would be nice if EMC would keep their compatibility statement fully up to date. Since simply doing a backup using Retrospect 6.1 on Snow Leopard trashes your system (uncompresses all hfs compressed files and updates the last modification time), I have to decide if I want to quit using Retrospect (which I've used since the very first release something like 20 years ago), or purchase v8.
  14. If Retrospect 6.1 is stated to be incompatible with OS X 10.6, then it is reasonable to expect that Dantz knows why it is incompatible, and know what are the most obvious symptoms of said incompatibility. Given that knowledge, it is also reasonable to expect them to be willing to explain, if possible, damage to a user's system caused by that incompatibility. I haven't upgraded to 8.x yet either because of the tremendous number of bugs and usability issues I encountered when I tried it out. I also didn't realize it would damage my system - just dumb luck, and complacency due to Time Machine, that I didn't encounter it myself.
  15. The current Snow Leopard compatibility statement says 8.1.622 says it is 10.6 compatible, but then later says there are major known problems. The UI script options bug, and that compressed system files are reloaded uncompressed I would consider major bugs. I've also found a number of posts as recent as a couple of weeks ago complaining of constant crashes under 10.6 and documenting problems with Retro Client backup of Snow Leopard systems. I didn't see any mention of build numbers in these posts. Yet, in the release notes for 622, it has as fixed: 21548: Snow Leopard: Scripts: No options displaying Build 626 release notes say this is fixed: 23640: Can't backup or restore of 10.6.1 large compressed files properly The current statement is KB 9723 and is dated 10/12/2009. Is there a current, accurate, Snow Leopard compatibility statement? What exactly is the state of 10.6 compatibility as of build 626?
  16. I ran into this also on certain catalog sets on a given volume, but not all. External volumes are by default created with 'Ignore permissions on volume' set - no ownership permissions are enforced. I unchecked that (i.e. enforce permissions on the volume - which is what you should want anyway), and reset the correct owner:group on the catalog sets and all is working now. You'd think that 'Ignore permissions on volume' would be the least restrictive permissions, but apparently Retrospect looks at the specific ownership/permissions even if the OS doesn't care about permissions on that volume.
  17. I did a full backup to disk of multiple computers - about 100GB worth. Verification was enabled, and there were no unexepected verify errors. After the backup was completed, I did a Tools/Verify and got the following error in the log. The execution error window showed it was to JPG files on the first computer I backed up. The verify continued and completed. What could be the problem? + Executing Verify at 5/19/2004 10:56 PM To backup set All Systems HD Offsite… Bad backup set header found (0x5001e23e at 2,722,218). Backup set format inconsistency (12 at 2722492) 2 files were not verified. 5/20/2004 1:46:02 AM: 3 execution errors. Remaining: 2 files, zero KB Completed: 798729 files, 108.8 GB Performance: 244.8 MB/minute Duration: 02:49:14 Quit at 5/21/2004 10:38 PM
  18. I didn't see someone had responded after 9 days, and never got an email notification... Mac OS 10.3, Retrospect 5.0.238, Backup device is an internal ATA hard drive.
  19. > If so, why worry about OS 9 at all? Why not simply run Retrospect while booted > in OS X and Restore to the empty volume? Well... Some of my systems cannot boot from Firewire. I have one bootable OS X volume. It is quite simple to build a bootable OS 9 CD containing Retrospect ready to go. I boot from CD and can then perform a restore on a clean disk (if Retrospect would let me do it for OS X). I've done this more than once for OS 9, both locally and on a remote system. I have never had to reinstall OS 9 to do a restore. I don't think you can do that with OS X and Retrospect. > If using OS 9 works for you, by all means do it. But I don't expect Dantz to >add functionality to Retrospect to give more support to an OS that Apple has >made clear will have only a limited role in the future. I'm not asking for more OS 9 support. I'm asking to be able to do a restore without having to reinstall OS X on an empty disk. This should be technically possible from OS 9, and it is trivial to build a bootable OI 9 CD, although it may be that Apple doesn't externalize what is required. I really don't care if the restore is from OS 9 or OS X. I should be able to restore an OS X volume after a catastrophic failure without having to first reinstall an OS. And, I should be able to do the restore by booting from a CD. BTW, the Retrospect User's Guide indicates that you have to do a live install (pg 117-119), and I thought I had read somewhere that this was a requirement - that restoring to a clean volume from another OS X drive was not an option. Where is it documented that you can restore a bootable system to a clean volume? (Yes, it is logical that it should work, but logic doesn't always apply).
  20. I have used OS 9 Disk Copy 6.4 numerous times to backup and restore an OS X system disk from OS 9. Simply "Create Image From Volume" to make the backup (make sure it is a read/write image, or the restored disk will be read-only). To restore, mount the image and do a 'Clone' from the mounted image to the OS X disk-to-be. If the two are the same size, it does a block copy. However, if they are different sizes, Disk Copy "Clone" does a file by file copy. The result is a fully intact bootable OS X disk restored from OS 9. I have done this with both 10.1.x and 10.2. The question for Dantz... If I can do this using Disk Copy, the capability clearly exists in OS 9. Why can't I do an OS X restore using Retrospect from OS 9? When will I be able to? Having to do a OS X install, followed by a Retrospect Install, followed by a full restore is something only Windoze users should have to do.
  21. I have used OS 9 Disk Copy 6.4 numerous times to backup and restore an OS X system disk from OS 9. Simply "Create Image From Volume" to make the backup (make sure it is a read/write image, or the restored disk will be read-only). To restore, mount the image and do a 'Clone' from the mounted image to the OS X disk-to-be. If the two are the same size, it does a block copy. However, if they are different sizes, Disk Copy "Clone" does a file by file copy. The result is a fully intact bootable OS X disk restored from OS 9. I have done this with both 10.1.x and 10.2. The question for Dantz... If I can do this using Disk Copy, the capability clearly exists in OS 9. Why can't I do an OS X restore using Retrospect from OS 9? When will I be able to? Having to do a OS X install, followed by a Retrospect Install, followed by a full restore is something only Windoze users should have to do.
  22. Your hardware compatibility note says: "This drive has slow performance because it does not support continuous write commands. Retrospect has to sync the cache after each write command." Obviously, whoever certified the drive observed something in regards to performance. The specifics aren't recorded somewhere that tech support people can get access to?
  23. Your hardware compatibility table says the performance with a Pioneer DVR-104 (Mac OS X) is poor because Retrospect has to flush the buffer for each write due to deficiencies in the drive. Exactly what is "poor performance". I found one report claiming 78 MB/min (full DVD 1x). However, I've found a couple of unsubstantiated references to under 10MB/min, which isn't poor - it's abysmal. Is this report accurate? Does this apply to all levels of firmware on the 104? What about on the retail drive (which isn't listed as supported). Why does Retrospect have to flush the buffer after every write? Toast doesn't when it is writing a DVD. Is this something unique to packet writing?
  24. Come on... Give me a number. When you certified the drive, what kind of performance did you get, and using what system for a server? If you back up 4 gigs of OS 9 and OS X, how many MB/min did you get?
  25. I was getting the elem.c-812 Assertion check in OS X every time I backed up a local volume to a disk file. This occurred at the very end of the backup, just before verification. It didn't happen backing up to CD or tape. This is with 5.0.205. As suggested, removing the 2.6 driver update cured the problem.
×