Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Maser

  1. I had 4 test FIleMaker database files. I back things up to a disk media set on a Thunderbolt RAID connected to a Mac Mini -- (no tapes, no DVDs, etc..) If I restore them to the HD of the Retro 10.5 engine computer (running 10.9), the restore finish at a speed of approximately 1,100MB/min. This is about what I would expect. If I restore the same 4 files to the HD of my client computer (also running 10.9) over Gigabit Ethernet -- the files restored at about 100 times *slower*: 10.8 MB/min. I tried this restore-to-client restore twice (after having rebooted both client and server machine). This seems awfully slow. Has anybody else gotten similar slow restore speeds after upgrading to 10.9? Or have I just not restored anything directly to a client in a while that I've just not noticed this?
  2. I just use proactive backups -- what usually happens is that users get backed up as soon as they log in in the morning and that's sufficient. I back up my servers, etc (which stay logged in) at night.
  3. You should be able to remove the missing source by highlighting the volume and clicking the "remove" button in Sources in the console (I just did this in 10.5). Worst case, just remove the client entirely and readd it?
  4. Console and engine are working fine here under 10.9. I need to check a restore with the 10.5 client fairly soon, though.
  5. Automatic re-running Groom scripts should be stopped if you stop the engine, then move the Catalog file from it's normal location and restart the engine. The script will try to run, then stop because it can't find the catalog file.
  6. Yes -- I run a groom script monthly on each of my media sets. However, the number of Past Backups for any client is supposed to always reflect what the number of backups to keep in the groom settings is set at. For example, I back up the "Users" folder of my client computers and that is set to keep 60 backups. Past Backups always shows 60 backups for each "Users" folder for each client. That works as expected. This is only "failing" for the servers where I am backing up the entire boot volume. And I'm pretty sure this is new behavior from the 10.2/10.5 time frames.
  7. I reported something, but am wondering if anybody else can reproduce this. I backup 3 Mac OSX 10.8.5 Servers -- each has two HDs set up in a Raid 0 (mirroring) capacity with the OS and all other files on it. I backup these entire server volumes to two different media sets (one set backs up two servers, another backs up just one server). The media sets are set for grooming -- the one with two is set to keep 90 backups, the other one set to keep 183 backups (3 months and 6 months, respectively.) With 10.5 (and I can't be sure this wasn't the case with 10.2, but I think maybe it also was), the number of Past Backups is seemingly ignoring what I have set. For the set supposedly retaining 183 backups -- I currently have 207 Past Backups. For the set retaining 90 backups -- I had over 120 backups when I noticed this. I am able to manually delete Past Backups, run a groom with no issues and rebuild the catalog files without issue. But the number of Past Backups continues to grow beyond what value I have set. Now, I have seen similar behavior before -- but *only* when upgrading from 10.7 Server to 10.8 server (about a year ago) -- in which case I could probably accept the answer that the "volume" was significantly changed by the upgrade. But apart from installing the Apple OS updates, no changes have been made to the server volumes (both RAID hard disks have never been replaced or the mirror rebuilt, etc...) Does anybody else have a similar setup that might be experiencing the same thing?
  8. So, this happened to me, don't let it happen to you... Through a unique set of circumstances, I believe I did the following: Mac engine upgraded to 10.5 -- worked fine and running concurrent backups as normal. One Windows 8 client -- with the Retro 8.1 client installed -- had been off-line for about a month, so I turned it on to update it to the Retro 8.5 client. I *think* -- when the client computer was on-line -- the engine snagged it for a proactive backup. And while that activity was running (not sure at what point), I manually installed the 8.5 client over the 8.1 client (with no apparent problems.) This caused the engine to stop working. I could no longer log into the console and no other backups were running after about an hour so I had to stop the engine (the 10-minute stop) (I sent in a bunch of logs and a spin dump). I can't say this is a *new* bug with 10.5, either, but more an example of an extremely rare set of circumstances. What to take from this? Don't manually update a client that is currently being backed up. That will confuse the engine... - Steve
  9. Release notes here: http://www.retrospect.com/en/documentation/user_guide/mac10/release_notes New clients for Mac and Windows, too. Significant performance increases, up to 100% faster (!)
  10. I would suggest rebuilding the catalog of at least one of your media sets and see if that fixes the problem of being unable to set the groom settings. (However, I do not store anything on NFS mounts, so I can't speak to how well the program works when you put your disk media sets on one of those...)
  11. For problem #1 -- did you quit and restart the console? I believe that the list of Past Backups does not refresh if you have left the console up and running continually (I think it only updates when the console is opened...) Problem #2 -- I can't reproduce here on a new media set. HOWEVER -- I have seen if you change the number of backups to keep on an existing set that has already been written to numerous times, an activity will run to change the catalog size to reflect how many backups you are keeping -- so it's possible that activity was running depending on what you were working with.
  12. Yes, this has been how it's designed by default. If you don't use a Favorite Folder, it has to scan the entire volume before processing your selection/rule. Defining a Favorite Folder is the way to go here.
  13. What gets slower? I find that as Media sets get larger -- if they are not password-protected media sets -- the console takes longer to open because the Media Sets are being "read" each time the console is opened. When I moved to (some) password-protected media sets, the console opens (somewhat) faster...
  14. Is this just a question of the console not updating fast enough? If you quit and relaunch the console, is it still showing as running?
  15. No, I mean what is running *in Retrospect's Console* when you restart?
  16. How many concurrent Proactive Scripts do you have running? Do you have *any* activities running when you try to stop the engine?
  17. If there's an existing process running, clicking "Stop" can take up to 10 minutes (in my experience) to stop whatever is going on. You don't want things to *immediately* stop as that could lead to corrupt catalog files... But, in general, if there are no processes running, "Stop" should stop the engine within a minute (or less)
  18. I am using 10.1 with Mountain Lion. There are a few bugs with 10.1 that I hope 10.2 will fix (soon -- issues with Grooming are one that they know about) -- but I do not believe they are related to Mountain Lion.
  19. I find that multiple concurrent proactive activities can cause SPODs -- particularly when getting to the "closing" state of a client backup. That's fairly consistent for me when generating SPODs
  20. I think this method stopped working with 10.7. It still does not work in 10.8. I believe this is intentional by Apple for security reasons...
  21. Does the server have a static IP address? I had a similar problem a few weeks ago when I moved my server (and all my clients) to a new subnet. Even though the clients were added by *hostname*, I think Retrospect cached the IP addresses instead. I had to readd all my clients to get them backing up again. - Steve
  22. So I ran this on my computer (which has xCode installed) and I backup the /Users folder as a Favorite Folder maser$ sudo find /Users -type d -exec ls -dlF {} \; | grep '^d.........[@+]' | wc -l 3582 So, you are saying I should see 3582 *.2 = 716 seconds of savings here? Approximately 12 minutes when building the snapshot after each backup? Or not that much in savings as all of my backups are over Ethernet?
  23. So, my report: I groomed 3 media sets with the 10.1 GM over the weekend. Two worked as expected. One of them (which I groom every week), reported I had to rebuild the catalog file. I rebuilt the catalog file and the subsequent groom worked. (I'm currently logging things to see if I can reproduce this one...)
  24. I have not used the 10.1 GM for grooming yet (I will do so this weekend), but I was able to use the 10.1 beta with minor issues (sometimes I had to rebuild my catalogs before they could be groomed correctly -- but the log throws up an error when this happens.) I am not using the defined policy, though -- I keep a specific number of backups for each client in the media set.
  25. Surprised there was not an announcement here: but it's now out: http://retrospect.com/en/support/downloads
  • Create New...