Jump to content

Maser

Members
  • Posts

    2,054
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Maser

  1. I find changing the number of backups to groom works best if: 1) No other activities are going on 2) You give it *time* to do this. When you reduce the number of backups to groom, this touches the catalog file because it has to modify the catalog file to only show you the number of Past Backups visible after you make that change. But, usually *reducing* the number of past backups to keep goes pretty quick (at least it does here when I've done it recently.) Increasing the number -- assuming no groom has been run) takes longer as it has to search the media set for the snapshots to readd them to the catalog. Meaning if I had a set set for 50 and reduce it to 10, it goes fairly quick, but if I then return it to 50, it takes a while (sometimes more than an hour depending on how many sources are in the set...) From what I've been able to observe, while the selection of the grooming changes *is* a preference, the actions taken after you make that change require you wait for the catalog to be modified.
  2. Well, depending on what rules you are testing, you could set up a Favorite Folder containing a subset of what you think should be affected by the rule and just back that up to a temporary disk media set on the engine hard disk (for example) That's what I usually do when testing rules as working with the Preview doesn't always show me what I think it should.
  3. Is it a question of starting the engine *after* you mount the encrypted volume where it works vs. when it doesn't?
  4. Not really. The only thing that might happen when you restore old configuration files would be backups that you had scheduled will run immediately if the scheduled date has passed. (Well, including any additional changes to the actual *configuration* you might have to redo since that backup date of the config files...) But the configuration files otherwise have not much to do with the catalog files/media sets.
  5. He means -- run the copy without having any user logged in (leave it at the login script). For me, I've been running Retrospect for years and basically ignore any "compare" messages. You should always test restoring files to make sure things work as you expect.
  6. Those are all normal, too. Those are log files that are constantly in use, so by the time they are compared, they are different from the state they were in when they were backed up.
  7. Basically Dave is on the money -- CCC does not do a "compare" phase after a file copy (it does a verification phase if you do a *block* copy -- but only verification of the "blocks". Retrospect is basically telling you the files in question have been moved/deleted/changed since they were copied because (I'm guessing) you were using the computer while it was being copied?
  8. Post the copy log with the errors and we could comment accordingly.
  9. I'm just suggesting that it's not a bug that could be fixed if it's more a question of how you use the program with the constrictions of the operating system.
  10. Yes -- but my question was more of if you do the following: 1) stop the engine 2) Mount the drive 3) Start the engine 4) Clean up the sources so that only one instance of the active volumes on the external drive show 5) Stop the engine. Leave the drive mounted 6) *Restart the engine* Do the drives show as you expect? Or are they now still showing *two* instances of the external drive volumes?
  11. (I don't mind helping when I can -- I check forums while other stuff is running that I don't need to watch...) So, you have two instances of the external partitions. What if you remove the "bad" ones now -- do you get one set of partitions that stay there?
  12. Wait -- if the problem happens when you "restart your mac" -- how are you reproducing the problem when you are *not* restarting your mac? If you mount the volumes by plugging in the external drive, start the engine, make sure the volume on the external drive are visible in "sources", then *stop* the engine and restart the engine (with the external drive still connected)-- are you saying that the external drive partitions are *gone* when you go back into the console?
  13. In the client preferences, you can turn off the "Notification" settings -- is that what you are looking for?
  14. So, what happens if you do this: 1) Shut down your mac. Connect the external drive powered on 2) Restart your mac. (I'm assuming that Retrospect automatically logs in)? 3) Do you automatically log into an account at this point? Or do you boot to a login screen? Remember -- by default, external drives are *not mounted* until you log in. This command will mount the drives (so Retrospect will see them) at startup if you leave the machine at the login screen: defaults write /Library/Preferences/SystemConfiguration/autodiskmount AutomountDisksWithoutUserLogin -bool true (I think -- it's been a while since I used it...) But, my guess is that is your problem -- you restart the engine, the drives are *not mounted*, so the engine doesn't see them at the time the engine finishes starting up and you then open the console and the drives are missing from the sources. You might also get around this by not having the engine start automatically and just have it start when you know the drives are mounted.
  15. Sorry, I misread this thread... Can you give a more detailed description of what you mean by sources and on what machine you are "restarting"? is this the engine machine that has this external drive connected to it? Are you running the console from the engine machine? What is the name of the internal hard disk as well as the partitions on the external drive, etc.... (as for if Retrospect is being actively maintained -- I believe it is even after the sale of Sonic -- I don't think the Retrospect team is *that* large, so they appear to alternate between Windows releases and Mac releases accordingly...)
  16. There seems to be a disconnect in when the "config80.dat" file is updated (which flushes the edits to your sources and scripts). What seems to be a common way to flush the edits to the file is to open and close the Console preferences (you don't have to change anything). That should make them "stick" better.
  17. I think (and it's been a while since I tried this), that sources will be backed up *in the order you add them to the script*. I don't think it's alphabetical by default -- it's just that's they way most people would think about doing this. But, as you've surmised, there's no way to reorder things in an existing script. If you use a "proactive" script, you can change the "schedule" of upcoming activities to (mostly) change the order of backups clients -- but that assumes all the clients would be on-line, etc...
  18. Do you have grooming off for your media set, but it was on previously? The size of the catalog is somewhat proportional to how many "Past Backups" you can see for the media set, too. Unfortunately, I don't use tape. If tape media sets are like disk media sets, the snapshots are (I think) stored in the media set, so the only thing recreated during a rebuild is the *catalog* file. But, I'm guessing about tape behavior. Earlier snapshots, though, are faster to retrieve as there's not as much "matching" that needs to be done to create the snapshot to restore -- that's fairly typical in my experience with disk media sets, so I wouldn't think tape would be that much different in this case.
  19. Do you have the catalog set to be compressed? IIRC, when you do a catalog rebuild, the catalog will *not* be compressed until you take some action on the catalog *after* the rebuild has finished. I think I filed a feature request about this one as it's not necessarily a bug, but a design choice. As for the speed of the rebuild -- how many backups were on the set? It might be that the first 69G was the *first* backup and then everything after that was incremental -- which will take longer to create the snapshots in the catalog file.
  20. If you are trying to back up your server, you need the edition of the software (serial number, actually) that allows you to back up "Mac OS X Server". Which version of Retrospect did you install?
  21. Are you creating a new script or copying an existing script? There seems to be a bug in copying that can sometimes result in what you see.
  22. It's "normal" in the sense that the SPOD shows up while the preview is building. I see this too -- eventually, the SPOD goes away and the results of your preview should be shown. (It's all a function of what you are trying to preview, how many files, how far back the backup is in the media set, etc. as to how long it takes to build/show the preview...)
  23. How did you add the mac to the engine? By IP address/hostname? Or by multicast?
×
×
  • Create New...