Jump to content

CallMeDave

Members
  • Posts

    5,150
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by CallMeDave

  1. > I also respect the time others use trying to get help... Then you're going to have to craft a post that makes sense to readers. > Looking at Activity Monitor Scheduled I see details of scripts. No, you don't. Activity Monitor doesn't have anything to do with Retrospect scripts. > I guess 204 191 191 cop are the type of backup. If you say so. It's your nickle. > I know created these scripts. {snip} > I would like to know how I created each one I'd say that the best person to ask (and answer) this question is sitting in front of your monitor as you read this. Dave
  2. > I reloaded my original catalog from 8 months ago and now it works. Assuming that this means you had backups of your Catalog files, this is a good thing; everybody should keep backups of these critical data files. > Only issue is that it will go corrupt in a two or three days How do you know? Please describe events that have already occurred, instead of events you anticipate. But if you suspect that your Catalog will become corrupt, now would be an excellent time to describe, completely and accurately, your hardware and software configuration. While Retrospect users do sometimes report corrupted Catalog files, a system where it happens regularly probably has an issue.
  3. Quote: I knew version 6 couldn't write to version 5 backup sets, but not that 6.1 can't write to 6.0... That's not what it says. 6.1 _can_ write to a 6.0 Backup Set. From then on, that Backup Set can _only_ be used with 6.1. Not quite so painful...
  4. Quote: recently backup has failed with the following messages for all of the folders I need to back up You'll need to provide more information before readers will have a clear understanding of what you're doing. For example: - What Type of Backup Set are you using? - When, exactly, does the message appear? - Can you successfully create a new Backup Set and use that? - Can you use {Tools->Repair->Update existing Backup Set}?
  5. Quote: could someone give us some alternative products. I know of no other product that can write incrementally to multiple media, spanning files across members as space requires. Heck, I'd be happy to find a program that could write to multiple disk images for later (DAO) burning, but there's nothing that I know of that will do that, either.
  6. Quote: After backup I disconnect the external disk and store it in a fireproof safe in the other end of the house. Magnetic information is scrambled at a much lower temperture then it takes for paper to burn. So unless the safe is rated for data, you might end up with an unreadable hard drive if there's a fire.
  7. > Is this the same problem? Yes. > Any known tricks to prevent this? No. So far, people bitten by this bug have not been able to come together and expose what they all might have in common. I've never, ever seen this happen on any machine I've used. Others seem to see it often.
  8. Quote: if it takes them 5 months to still not address a bug caused by sleeping, then we're dealing with an EXTREMELY scaled-down staff here. Or, the staff simply didn't have the steps to reproduce a problem that was reported in the field. Often, a software developer depends on complete user generated reports to discover bugs. These can be received from tech support interactions (real-time and two-way). Or they can be found in online discussions, as long as those discussions are complete and accurate. It was a couple of years or so ago that a problem was reported here on the Forum that Retrospect was painfully slow for some users. It took some back and forth before the common configuration was found to be RAID arrays, and only after that online discovery was made was Dantz (I _think_ it might have been before EMC) able to address it. Claimed confirmation that this is a sleep/wake issue has only been reported this weekend. Perhaps EMCInsignia testing can try it now. Or perhaps they don't have ready access to Apple's newest machines, and will have to test it at the Apple third party testing lab in Cupertino. Dave
  9. Quote: Hi, I noticed this question gets asked every so often, and it seems about time to ask it again: does Retrospect for Mac support SFTP? No. > Alternatively, does it support WebDAV? No, other then you might be able to use a Finder mounted WebDAV volume as a location to store a File Backup Set. Would need some testing/configuring, and it might not work at all depending on the permission matrix of the remote volume.
  10. Quote: I wonder if it is possible to span the backup catalog. It seems the problem is in rebuilding the catalog itself. The question suggests either you're unfamiliar with how Retrospect works, or that this discussion has wandered from accuracy to assumption. - ARE you using a File Backup Set? If the answer is yes, then the data file and the catalog file are always together, like bread and butter. In past times, a File Backup Set (and before that, a File Storage Set) lived as a single file, which included the data and the catalog information. The former was stored in the file's data fork, while the latter was stored in the file's resource fork. But apple's HFS file system had/has a limit to how much data can be held in a file's resource fork, and since catalog needs grow with larger file counts, OS X brought on a need to get past that limit. So splitting a File Backup Set was introduced with Retrospect 5.0. But in general, there shouldn't be a need to rebuild a File Backup Set's catalog file, since it should live alongside the data. So, why do you need to? If you want to span backup _data_ across volumes, you can use a Removable Backup Set, and store the catalog file on another drive/volume/sharepoint. Note that Removable Backup Sets have a 1 TB limit per volume. Catalog files cannot be spanned; they are a file that is activly read from/written to during backup or restore. Other Types of Backup Sets are different; the catalog file is truly independant of the data, and can be lost even if the data is secure. Rebuilding is more likley necessary. It may be that the other Types of Backup Sets can rebuld large datasources easier then the special File Backup Set. > I see this as a bug in retrospect myself It depends on what "this" is. If your 531 GB File Backup Set has so many files that Retrospect can't get enough memory to handle them all (and note that it's the number of files, not the size of them that matters), then it's a limitation of the program as opposed to a bug per se. - How many files in the Backup Set? - How many sessions in the Backup Set?
  11. > Way to go, Dave, defending a multi-million dollar corporation... I did no such thing. I was merely ribbing a post suggesting that it was costly to conduct what seems to me, to be an easily proven theory ("Retrospect will loose connectivity to any Core2Duo client that has awoken from sleep (to an ethernet connection)"). Especially considering that I suggested that you focus on answering this specific question weeks ago. Then I defended a particular employee of that corporation, someone who has proven himself to be an advocate for that corporation's product(s). > that has put out a faulty product, If the newest hardware from Apple includes a specific incompatibility with the Retrospect OS X Client software, that doesn't mean that the software was "faulty" when it was released. It simply means that things have changed and the developer has not addressed the change. > ...completely ignored its Macintosh customers for years, They may not have provided as much attention as you and I wish that they had, but "completely ignored" is an insult to the men and women who have been providing what ever attention the company gave over the last few years. > ...and has all but abandoned Macintosh support altogether. As best as can be discerned from news reports and public announcements, the Windows product and the Macintosh product appear to now share about the same level of support. It's not very great. > There are also very credible reports on the Internet that > all Macintosh development on Retrospect has stopped at the > company and their Macintosh engineers have been dismissed. What does it take to make a report on the Internets "credible?" Even though Larry Zulch left EMC shortly after writing his public letter to the Retrospect community, I have no reason to doubt his assertion that Laurie Gill is still involved in the Retrospect program. I don't hold out much hope that there'll ever be a true "new" version of the program, but I also don't doubt Robin's public announcement that there will be an update for Leopard. That takes development effort. > Meanwhile, this is a bug that has been present ever since the Core 2 > Duo Intel Macs shipped in October 2006, so therefore the bug has been > around for at least 5 months without even a single update from EMC. If this is, in fact, a bug with this specific hardware, as you claim your tests confirm, then your timeline seems reasonable. Now I'm really angry! > it's consultants like myself who have ... to deal with the > nightmare when the product fails to work as advertised. Oh. My. God. You recommend products to your clients based on how they're _advertised?_ And they pay you money for that? Dave
  12. If you visit the "run" menu and select an existing script, Retrospect will then be in "unattended" mode and will behave the same as if the script had been scheduled. You can use the "Control" menu to switch between "Run Unattended" and "Run Interactively" anytime you want to. Note how the cursor changes when these modes are switched.
  13. First of all, thanks for a complete, step-by-step account of what you did. It always makes it easier to spot what went wrong. For you, step 2 (part was unnecessary. The only reason to install system software on a new drive is when you are doing a "live" restore. Since you have multiple boot sources available, such a method wasn't warranted. If step 1 included copying over all the files from the old drive into a Backup Set, then step 2 should have been simply to Restore all of those copied files to a new, freshly formatted, empty volume. Done. For your needs, either Backup/Restore or Duplicate with Retrospect will work. There are also lots of other options, such as CCC that you mentioned, or Disk Utility or SuperDuper!
  14. Quote: I just want everybody to know that I have done EXTENSIVE testing on this problem this week at a gigantic cost to myself, and this is the problem that EMC Insignia has yet to fix with Retrospect for Macintosh: If any Intel core 2 duo Macintosh goes to sleep while running the Retrospect client, when it awakes from sleep, the Retrospect client says that it is "on" but in fact it is no longer broadcasting itself to the Retrospect server Wow, and it seems like only 17 days ago that you reported: "...as far as I can tell, it seems to happen after the machine goes to sleep." I can only imagine the magnitude of the expense necessary to prove a null hypothesis on this one... Quote: And Robin Mayoff, who religiously reads these forums, why are you not reporting this to your engineers? Yeah, Robin. It's 6:24 pm Pacific Daylight Time on a Friday; why haven't you logged or updated your bug database with this new specific information yet?
  15. And people in the forums keep saying that Dave and I are difficult... They do? I suppose I shouldn't be expecting any virtual Easter baskets again this year...
  16. Quote: Not sure if this is due to a problem with the lacie, Retrospect crashing or a new OS X update. There have been other reported problems with the LaCie Bigs (this is two drives stripped by some custom hardware in the LaCie case, right?). You don't say how large your Backup Set file is, but if you don't have any files on the drive other then the File Backup Set and it's companion catalog file, then with 112.63 GB free your file must be very, very large. You may be pushing the limits of what the program can do with that Type of Backup Set. What happens when you use "Update Existing Catalog File?" Dave
  17. An .rcu file doesn't install a completely new client application, it only makes changes to the client software to which it's connected. It's part of Retrospect's "downloadable services," and it depends only on communication with the client. The default install location for the client application matters _only_ to the shell script in /Library/StartupItems/RetroClient/. Just another reason to miss the passing of the Alias Manager in "Classic" Mac OS; used to be you could put an alias in System Folder:StartupItems: and then move the target file anywhere, and the system would still find it. Oh well, stability has its price... Dave
  18. Quote: ... you will not be able to push the client from Retrospect ??? You can never push a client install from Retrospect; all you can do is push a client _upgrade_ (via an rcu file). This ability should not be impacted by the client location on the drive. I agree that the configuration will be "unsupported," but it should work fine. Dave
  19. Quote: Pioneer DVD DL (5.12) v AB09 - What's the model of the Pioneer DVD DL drive? - What type of DVD media are you writing to? -R, +R, etc... ?
  20. Quote: The long term fix is to update to 10.4.9 on the computer with ACLs Robin, your initial post in this thread suggested that it was only rumor that the bug was fixed in 10.4.9. Does this mean that there is confirmation that Apple fixed it with this last Tiger release? Dave
  21. If moving/removing/renaming the preference file doesn't do it, I'd suggest opening up Console and watch the System log as you attempt to launch. Retrospect uses some system-wide authentication APIs that might identify themselves during a failed launch attempt. Dave
  22. If the program asserts simply by visiting Configure->Clients->YourClient->Configure(button)->Configure(tab) then it has nothing to do with your Backup Set type. The term "unsupported" means, in this context, that Dantz/EMC Dantz/EMCInsignia never tested Retrospect with any hardware other then stock models from Apple. Upgrade cards might work, they might not, but they're not qualified by the software publisher whos product you're using. Since there are reports on this thread of the same assert on Windows clients 6.5.x and 7.x, as well as Linux client, it's reasonable to surmise that it's a Retrospect (Macinsosh) issue, in how it's communicating (or attempting to communicate) with clients. When the program gives an assertion error, it also writes a log to your /Preferences/Library/Retrospect/ folder. I'm going to have to suggest that you open a support incident with EMC and send that log to them. Do it while you can...! Dave
  23. Quote: Macintosh Retrospect will crash and fail to back up my two Windows network clients with the above error in a dialog box that only offers a "quit" button. Does the assert occur at the same place that the second poster reported?: I can reproduce easily by going to Configure->Clients, click "Configure..." for this client, then click on the Configure tab in the "Client Configuration" window. As soon as I click the Configure tab I get this assertion.
  24. > It seems that this happens at every reboot. Well, _does_ this happen at every reboot? Pease re-read comment #95222 above about the language "active" not being used in the software that you're using; the words in the "status" field of the Retrospect Client application are most helpful in describing what's happening. If the client doesn't start when the system starts, you have likely moved it from its default location in /Applications/ Dave
  25. Quote: Seems silly that Retrospect works the way it does. Toast 6, not even the current version of Toast, burns to the new drive and recognizes the dual layer support. Silly? How would you feel if your Optical Backup Set was unable to backup to the same partially-filled recordable disk over and over again until it was filled? Would you rather have it burn individual "sessions" the way Toast can, with each new burn resulting in a new volume and all its associated overhead? Retrospect works the way it does (which is totally different then Toast or DiskBurner) so that it can backup small files or large files, span files large or small across disks, all without loosing large amounts of disk capacity to overhead. Even when Dantz/Dantz-EMC/EMCInsignia was churning out device support updates more quickly, some drives were never qualified because the hardware wasn't capable of supporting packet writing reliably. Dave
×
×
  • Create New...