Jump to content

CallMeDave

Members
  • Posts

    5,150
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by CallMeDave

  1. Retrospect 10 is supported under Mac OS X Server 10.6.8 and later http://www.retrospec...ac/requirements "XServe RAID" isn't a computer, it's an accessory. We still don't know the version of Mac OS being used with the Retrospect OS X Client software. "This one" is presumably the XServe controlling the XServe RAID?
  2. IIRC Retrospect uses the UUID of root volumes; no way to reconnect old hardware to new. It's a deliberate feature, not a bug.
  3. Perhaps some detail about the machine at issue would help. What OS? What client version? What is the Source being used for the backup? Have you tried testing with a smaller source volume on the same client machine? Or using a Favorite Folder on whatever source volume is misbehaving, to limit your tests to a smaller data set?
  4. You wrote: > The only remedy is to delete the folders and start all over. What we know for sure is deleting the folders and starting over remedied the situation for you. But your claim is much more broad then that. Your claim is that _nothing else_ will remedy the situation, which is pretty much impossible to prove, since you would have to show that you tried everything possible in the entire universe, which itself is impossible to prove. But what you could do is share the things that you did try, that were unsuccessful, in order to help readers (to whom you are appealing for assistance) get an idea of what's going on for you. On the other hand, if the only thing you tried was deleting the folders and starting over, knowing that would help readers, too.
  5. But it's Retrospect that's not working, so knowing the actual steps you have taken to configure Retrospect would be necessary for other Forum contributors to offer a solution. Mounting a share point in the Finder that you also want to use as a Retrospect Source is the most common mistakes Retrospect users make, and the volume name you provided (about which I previously requested confirmation) is another clue that your software setup is the cause of the failures. Feel free to provide more complete information; it's what will lead to an answer and an explanation of your experience. But I'm not feeling this as a software defect. -dave
  6. Since the fine folks at Livedrive seem to think it's necessary to withhold access to their knowledge base articles to non-subscribers, I needed to sign up for a trial account to learn that direct WebDAV access is only available to their higher tier "Pro" accounts. Having complete steps to reproduce will likely reveal it's a path name issue, but we'll need additional information to find that out. -dave
  7. I wouldn't go there before knowing the steps that were taken that resulted in the error. I'm the first person to recognize that WebDAV support in Retrospect isn't as robust as it needs to be, but I also recognize that user error is a very common cause of Retrospect problems. I went ahead and signed up for a Livedrive Briefcase, which provided an application that handled authentication and mounting of the storage volume (shown as /Volumes/LivedriveFS on my filesystem). Attempts to connect using the Finder to http://webdav.livedrive.com using my account email and password were unsuccessful. So the question becomes, how did you configure Retrospect to access the destination volume you were attempting to use as the Destination for (what I must assume to be) your Disk Media Set?
  8. Is webdav.livedrive.com-2 the name of the volume you've configured Retrospect to access?
  9. Since control list settings are portable with the file (with the proper tools, moving a file brings the ACL settings along intact) I would assume that a change to the ACL is a change to the file. To the part of the metadata that you changed? Add a user, you've changed the part of the metadata that stores users? It didn't; Retrospect 5-8 maintained dynamic POSIX information for each file in the Catalog, allowing for a permission change to be held in proxy until the need for restore. Because Retrospect doesn't maintain dynamic ACL information in the Catalog, just as the Catalog file doesn't maintain other information dynamically. Perhaps doing so was impossible, or too difficult, or simply Not a Good Idea. If changing some or any or all ACL information in a file causes Retrospect to not "match" that file to what's stored in the Catalog then Retrospect will, by design, back that file up again.
  10. Apple Mail has a Rule step of Run Applescript, so you could probably do it that way. Would require a machine with Mail running and checking, so there would have to be a user logged into OS X at all times.
  11. The design of Retrospect Disk Media Sets is to maintain the Catalog file separately from any Member of the Media Set. You'll notice that the default location for new Media Sets is /Application Support/Retrospect, so that might be a good idea in your case, too.
  12. Retrospect 9/10 support WebDAV volumes in addition to afp and smb/cifs.
  13. Mounting a shared Source volume on the Desktop of the machine hosting the Retrospect Engine is unrelated to, and will often interfere with, normal operation of Retrospect for Macintosh. "Shows up" where? How? Do you use the IBackup for Mac application in some capacity to access the drive without Retrospect? Is this product marketed as providing access via afp or smb? If not, seems like a waste of time trying to get Retrospect to do it this way. If so, what is the exact URL you used? Does the same URL work in the "Connect to server" dialog of OS X ? What happens when you try?
  14. man launchctl https://developer.ap...aunchctl.1.html (stoopid fourm truncating the text of my URL) **https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/launchctl.1.html**
  15. Your best chance at getting support via the user community here on the Forum would be to provide thorough and detailed information about what you are doing, and what you see when you do it. - At this point we (the readers) don't even know if you are hosting the Engine on the same Macintosh that is running the Console application, or if your unsuccessful experience are via another machine on your network. - We don't know what you see in the sidebar. - We don't know what you have tried to do,other then to scan for port 497, that did not fix things. - Etc. Would love to try and help. Would need more information to do so.
  16. I would think if the rdb naming convention were compromised, Retrospect would not be able to crawl the "slices" of data to rebuild or access. You could try and put the recovered files in a Disk Media Set structured folder (/Volume_Foo/Retrospect/Media_Set_Foo/1 Media_Set_Foo/) and then run a Catalog Rebuild on it. But I doubt the program would be able to do much with that other then spin its wheels. Someone should be going to jail for this...
  17. This is like saying "Aside from the pile of rocks in the truck bed, there are essentially no rocks in the truck." The Library folder in my home folder contains around 750,000 files. During a Restore, Retrospect would need to look at each and every one of those, a task which might reasonably (without knowing the networking situation involving this client/engine pair) take longer then 15 minutes. This is not to discount David's excellent point(s) regarding interface. Heck, I'd just be happier if the Operations Log provided more information throughout the various possible activities of the program, but its behavior is unchanged for versions going back 20+ years.
  18. Start client: sudo launchctl unload /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist Stop client: sudo launchctl load /Library/LaunchDaemons/com.retrospect.launchd.retroengine.plist
  19. The success (or failure) of multicast discovery can be effected by the physical network. If you're seeing unexpected behavior on multiple LANs, are there attributes shared among them? Same router(s)/switch(s)?
  20. Bummer. Since you're reporting an issue with hardware, perhaps you might consider providing readers with information about your equipment... Bummer
  21. Mac OS X does not allow two user processes to access the same remote volume at the same time. Mac OS X does not allow two mounted volumes to have the same name (whether they are the same share point or different share points) at the same time. Mac OS x will "protect itself" from having two volumes with the same name by appending a sequential number to the end of an already mounted remote volume's name. Retrospect doesn't do anything dynamic in this regard; so if you have configured a Member of a Disk Media Set to be found at /Volumes/Foo/ but after a restart you mount that same volume (so it's seen my OS X as /Volumes/Foo/) and you _THEN_ ask Retrospect to access the share point, it will be unable to do so; the name "Foo" is already taken, so OS X will only allow the volume to be on the path /Volumes/Foo-1/, which is _not_ the path Retrospect was configured to use. Result? Fail.* So instead of believing that having it mounted on the Desktop and also used by Retrospect is something you have been able to do and therefore is something you believe it is possible to do, come to an understanding that Retrospect will not provide reliable behavior if you do that. *hint that continuous attempts to mount the same volume might not be a good idea can be found in your 'mount' output: /Volumes/DS XXX Backup /Volumes/DS XXX Backup-1 /Volumes/DS XXX Backup-2 /Volumes/DS XXX Backup-3
  22. - Can you define a folder on CORE RAID 2 as a Favorite? - Can Retrospect scan/backup that Favorite?
  23. - Can you define a folder on CORE RAID 2 as a Favorite? - Can Retrospect scan/backup that Favorite?
  24. Retrospect backs up to Media Sets, which are comprised of the "set" of Catalog file and media Member. Retrospect can use networked volumes as Members of Disk Media Sets; you must Add them as as Source before you can use them as a Member. If you're trying to "see" a volume shared at /Volumes on the Engine host machine, that would lead to a failure if that machine had no user logged in to the Finder. Having Retrospect mount the share itself gets around that (although it does add its own potential for problems if you try and access the same share as a regular user while at the same time expecting Retrospect to access it too). Dave
×
×
  • Create New...