Jump to content

Maser

Members
  • Posts

    2,054
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by Maser

  1. The 10.1 beta seems to address some of the big client CPU hit. It's worth testing on your end...
  2. The 10.1 beta (which is available if you hunt for this) fixes this problem...
  3. So, FWIW -- we've been looking at CrashPlan here. This seems to have the same issue. The script will run at the prescribed time, but if the client is logged out (this is on a 10.8.2 mac), then no files are backed up... I'm sure this is an Apple issue, so direct your irritation at them, I think...
  4. Are some media sets configured for Grooming and some are not? This could explain why you see the differences in what is being shown in Past Backups...
  5. I see this as well. There is no "using Instant Scan" being logged for my Windows client backups (even though I know it's working). This, too, was from upgrading the client in-place.
  6. So, if you have a folder that contains files where some are backed up and some are not... What happens if you move that folder to another computer running the 10 client (with instant scan still enabled?)
  7. Is there something specific about the location/path name of the files that are being skipped? (Or is it an example of you have a folder with 100 files in them and only some of them are getting backed up?)
  8. 4-5M files probably shouldn't have taken any more than a couple of days (with your CPU). If you have problems rebuilding the catalog, please let us know (as I'm curious...)
  9. if it was me, I'd stop the engine, remove the catalog file for that media set, restart the engine (which will make the groom script fail because it can't find the console) and rebuild the catalog. I can only give a recent comparison of one of my disk media sets: on a 2.5G i5 Mac Mini with 8G RAM, my most recent groom script on a media set that contained about 3M files (600G) -- took 9:15 to run. Your media set (in size) is about 6-7 times bigger. If it has 6-7 times the number of *files* in it, it may take 6-7 times as long to actually run.
  10. Can you browse the favorite folder and see content from the engine/console machine?
  11. Groom speed is highly dependent on the number of *files* in the media set (and how many past backups you are grooming) -- as well as how fast the CPU is of the computer doing the groom. The *size* of the media set is not as important as how many files are in it. You didn't say what the CPU speed is of your Mac Mini (but I'm guessing if it's running 10.6.8, it's fairly old). CPU speed -- more than RAM or OS version or hard disk speed -- makes the most difference in how fast a Groom will run (all other things being equal...) When the groom activity actually displays the "segment X of Y" -- that's when it's actually grooming the media set. If you stop the groom now, you will need to rebuild your catalog file as it will be in an "unfinished groom" state. However, if it never changes the "X" number -- then it sounds like something would be wrong with that and you might have to do that.
  12. I'm not seeing that here, but I back up to "disk" media sets...
  13. Run the console a second time. There's a (bad) bug in the 10.0.1update in that the notification of the AES problem stops the notification of the Engine update. When you run the console the second time, it will prompt about the engine needing to be updated. (Somebody should have caught this one...)
  14. If you have a runaway groom, I think you should be able to stop it by first stopping the engine and then relocating the catalog file. When you restart the engine, the process won't be able to find the catalog file and then abort the groom. You will likely have to rebuild the catalog before you can do anything with the media set again, but it depends where the groom was when you stopped things...
  15. OK -- but consider this a request for an "enhancement" -- because it's a flawed design in this respect. I have 8 media sets -- all of them are fairly large. If I leave all of them unlocked, it can take the console up to 5 minutes to actually populate anything (the IOS app actually works better here). So, when I set up new media sets with Retro 10.0.1, I had left them accessible via script only -- which lets the console open in 15-30 seconds as expected. So, if a client is allowed (by the engine) to actually do restore on demand, then the client should be able to send a "temporarily unlock" signal to the engine for this purpose -- otherwise the media sets should stay locked.
  16. If you stop the "Retrospect" Pref and restart it -- then open the console -- *then* look at the log -- does the log say you are still running 9.0.2? If so, the upgrade didn't work (as you may have updated the console, but not the engine...) If you have the "Retrospect Client" pref -- then you installed the client for some reason and could uninstall that if you are only backing up your computer with the software on your computer.
  17. I just want to officially get this into the bug queue. While this was semi-broken in Retrospect 9, it is possible to set Grooming to keep up to 255 backups (if you set the number higher than 255, you get some random number generated.) Retrospect 10 has been changed so that you can only save *99* backups. This does not help with retention rates of a common "6 months of daily backups" need for grooming. I'm hoping this is fixed before the next 95 days go by before I'd need to groom my media set so I don't lose 3 months of backup unexpectedly...
  18. 10.0.1 -- is just a new console/engine update. It does not affect the behavior of the "retroisa" process on client machines. What we see here is that on machines with 4G RAM -- the performance hit is noticeable (even running just the engine on a 4G RAM machine). It's less noticeable on machines with 8G RAM.
  19. Run the console *twice*. The first time you run it after installing the 10.0.1 version, you just get that AES-warning message -- which appears to block the notification to upgrade the engine. If you quit/relaunch the console, you should get the prompt to update the engine to 10.0.1 (I reported this as soon as I saw it, too...)
  20. Well, your issue may be resolved by moving away from Retrospect, but it's not resolved for the rest of us that occasionally see this problem...
  21. So, FWIW -- I just saw this today with the Retrospect *10* engine (but a client still on Retrospect 9). Client was in another subnet on campus (which I could see via ARD), but the client started backing up (proactive script) while I had been watching the console for another, unrelated reason. So, I don't (yet) know if the problem will go away if the client is updated to Retrospect 10 or not. But I can guarantee the client was added via hostname...
  22. As far as I can tell, "restore on demand" does not work if the media sets are locked (ie, if they are AES-256 encrypted and you follow the default prompt to "remember password for scripted access") If I manually open the console and unlock the media sets, then the clients can see their backups and run a restore. But if the media sets are locked -- the client doesn't seem to be able to initiate an "unlock" to see the backup history -- because it's not "scripted" access. Or am I missing something obvious? (It seems wrong to me to leave encrypted media sets as "remember password for any access", but maybe that's what needs to be done?) - Steve
  23. I have seen this as well (though having just updated to Retrospect 10, I have not tested to see if they've fixed this yet). But -- with 9 -- I have added all my computers via hostname. If the computer has to go to the shop, I have *cloned* the computer to other hardware temporarily. The other hardware is pulling a different DHCP address at that point -- but the computer continues to back up (proactive backups). It may be that *proactive* backups are actually doing wider LAN searches than scheduled backups are for some reason. Maybe it's Tag-related, but I'd find that hard to believe, too... And, it may be some cruft left over from the fact I'm using a really old "config80.dat" file that's been around for a while -- or that all the clients have just been continual client *upgrades* (rather than removing the client and adding the updated client clean.) But I've *always* only ever added my clients by hostname (Add Source Directly...) And I see this daily. The clients are *not* limited to backup by having added them with a specific hostname.
  24. I think there is some info, but having done grooming ever since it was first announced, I think I can answer some of this: 1) Groom to "X" backups. (Say X=5 here...) If you run more than 5 backups for a source, you will only see the last 5 in "Past Backups". When you *groom* the media set, you will remove the unique data that is in the media set for the older-than-the-most-recent-5-backups. Fairly simple. If you have X set to 5, but haven't run a groom, if you change X to 10, you'll see a quick relookup activity run so that there would now be 10 Past Backups listed for the source (they are there, but haven't been groomed yet, so you can get them back). If you change X back to 5, then the first 5 backups will be hidden again. 2) If you manually delete a Past Backup and then Groom, it still grooms to whatever your current groom settings are. In the example above, if you have X=5, but have done 10 backups, but you manually delete one of the 5 *visible* Past Backups it will *not* refresh to bring "backup 6" back to the list -- that one is already marked to be groomed. So if you run a groom at that point, it will delete the first 5 backups (the non-visible ones) *plus* whatever backup you manually deleted. It will *not* only just groom the one backup your removed if you check the box to "groom now". (It would probably be nice if it did, though...) (EDIT: If you mistakenly "delete" a Past Backup, the only way to get it back -- if you haven't groomed yet -- is to rebuild the catalog file, I believe...) 3) If you delete a source -- the backups stay in the media set. You have to manually delete the visible past backups for that source and *then* run a Groom script -- so it will delete the visible and non-visible backups for that source. If you do not manually delete the visible past backups, any other groom just deletes the non-visible backups. 4) Groom to defined policy -- there's a KB article about this somewhere (or it's in the manual). Something along the lines of keeping X number of days, then one backup a week for Y months and then one backup a month beyond that. I don't use it because I want "X" backups
×
×
  • Create New...