Steve3 Posted September 6, 2006 Report Share Posted September 6, 2006 Hi all, I'm using Retro 7.5.6.105, mainly using disk backup sets to write to 2 750 gig external drives in an eSATA case. Backups and restores are working as expected. What I'm having trouble with is the grooming. In my Servers backup, I have it set to groom to the last 10 snapshots. If I configure: Backups Sets: Servers to Disk: Snapshots, I see only the 10 most recent snapshots for each source, as I'd expect. In the Summary tab, I've used 872.1gigs, with 176.0 gigs free. However, this does not correspond to the actual space used on disk. Between my 2 750 (698 actual) gig drives, I have a whole 10.3 gigs available- not 176. This set is using 100% of the first disk (with 539 megs left open), and is given 350gigs on the second volume, of which there are now 10.3 gigs left. Am I missing something that makes Retrospect purge the data unique to the 11th and later snapshots? It just doesn't seem to be purging, and I'm rapidly running out of storage space because of it. Thanks, Steve. Link to comment Share on other sites More sharing options...
Mayoff Posted September 6, 2006 Report Share Posted September 6, 2006 Space will only be groomed when the disk actually fills up or you manually/schedule a groom operation. http://kb.dantz.com/article.asp?article=7941&p=2 http://kb.dantz.com/article.asp?article=8146&p=2 All grooming operations will appear in the operations log along with the total data groomed away. Link to comment Share on other sites More sharing options...
Steve3 Posted September 6, 2006 Author Report Share Posted September 6, 2006 I've had both of those situations- the logs say my Clients to Disk script groomed out 44GB yesterday from 12:45 to 2:06PM, and my Clients and Servers scripts should groom every Saturday morning. Can you help me understand why the Summary tab tells me there are 176 gigs free, when the space on disk doesn't match that? Perhaps it's better understood as "the next time a groom script runs, it there will be 176 gigs free in the backup set"? I've had more than a couple "-1115 Disk Full, you must now recatalog" errors. Are these known to interfere with grooming? I have a manual groom of the Servers to Disk backup set running now, and I'm recataloging the Clients to Disk set, as it was the one that failed this weekend: Code: + Executing Weekend Groom at 9/3/2006 7:32 AM (Execution unit 3) Grooming Backup Set Clients to Disk... Groomed 200.0 MB from Backup Set Clients to Disk. Grooming Backup Set Clients to Disk failed, error -1115 (disk full) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. Can't compress Catalog File for Backup Set Clients to Disk, error -1 (unknown) 9/3/2006 8:37:18 AM: 2 execution errors Duration: 01:04:32 (00:00:13 idle/loading/preparing) I'll see how much free disk space there is after the Servers are finished grooming. I'm expecting 176 gigs..... Link to comment Share on other sites More sharing options...
Steve3 Posted September 6, 2006 Author Report Share Posted September 6, 2006 Nope, didn't get 176 gigs of free space. I got this for my efforts: Code: + Executing Groom Servers on demand at 9/6/2006 12:21 PM (Execution unit 4) Grooming Backup Set Servers to Disk... Groomed 1,532 KB from Backup Set Servers to Disk. Grooming Backup Set Servers to Disk failed, error -1115 (disk full) You must recreate the Backup Set's Catalog File. See the Retrospect User's Guide or online help for details on recreating Catalog Files. Can't compress Catalog File for Backup Set Servers to Disk, error -1 (unknown) 9/6/2006 1:25:01 PM: 2 execution errors Duration: 01:03:04 (00:01:11 idle/loading/preparing) Another "you must recreate the Backup Set's Catalog File" error. Yes, I know the disk is full. That's why I'm trying to groom it. Why are these Catalog Files so fragile? I've had to recreate the backup files a good half dozen times because of this exact error. C: has 53 gigs free, so it must be the first 750 gig drive that it's referring to, the one that now has 603megs open. It seems to me that I'm taking the steps to address the disk full situation, only to get a "I broke because your disk is full, now spend 7 hours rebuilding your catalog file" response from Retrospect. Link to comment Share on other sites More sharing options...
Mayoff Posted September 6, 2006 Report Share Posted September 6, 2006 If the catalog file is corrupt and requires a rebuild, then you MUST do that, otherwise you will have continued failures during backup and grooming. The problem will get worse until you recatalog. On my server I often drop down to 5 MB free on my backup disk and I never get the error -1115 disk full. Try to rebuild the catalog and try again. The catalog rebuild must complete without errors. What disk is the catalog file saved onto? Normally it is on the C drive. Also, do you have enough disk space to save 10 snapshots of every source drive? Maybe you will need to reduce the grooming value to 7 or 8 snapshots. Link to comment Share on other sites More sharing options...
Steve3 Posted September 6, 2006 Author Report Share Posted September 6, 2006 I have rebuilt the catalog a number of times, never with any logs of failures. I'm just frustrated that it seems to blow up so easily. I'm currently rebuilding my Clients catalog file, and now need to do the Servers- this just shouldn't happen. The catalog is saved to my C drive, which has 53 gigs available. I do have enough space for snapshots. My Servers set has all of one drive (698gigs) + 350 gigs of my 2nd drive to save to: 1048gigs. The backup set says it's using 872 of that, with 176 free. But there aren't 176gigs available on the system, there are 603megs on E:, and 10gigs on F: Without clearing up some space, my backups will fail soon. If I could get it to clear out the 176 gigs it claims are free, all would be well. Link to comment Share on other sites More sharing options...
Mayoff Posted September 6, 2006 Report Share Posted September 6, 2006 Which drive contains the default windows temp directory? When grooming takes place, Retrospect creates one temp file of about 650MB. Could Retrospect be trying to save the temp file to the E drive which is low on space? Link to comment Share on other sites More sharing options...
Steve3 Posted September 7, 2006 Author Report Share Posted September 7, 2006 I haven't knowingly changed the temp directory location... how would one verify that setting? Here's the interesting part: As mentioned above, I ran the recatalog on the Servers and Clients backup sets yesterday. Overnight, the Servers script ran, and did the following: Code: 9/7/2006 4:00:57 AM: Grooming Backup Set Servers to Disk... 9/7/2006 7:41:08 AM: Groomed 279.9 GB from Backup Set Servers to Disk. This looks reasonable for the free space on the drives- 184 gigs on E:, and 80gigs now open on F:, 5 hours and a number of client backups later. Now the only question is how to make it behave like this all the time, and not like yesterday afternoon, when I asked for a groom on demand and received the "-1115 disk full, you must recatalog" message. Link to comment Share on other sites More sharing options...
ComputerX Posted September 18, 2006 Report Share Posted September 18, 2006 Quote: I haven't knowingly changed the temp directory location... how would one verify that setting? System Properties (I right-click on "My Computer") -> Advanced tab -> Environmental Variables allows you to view and edit. I find "echo %temp%" and "echo %tmp" at a command prompt easier. Code: C:\>echo %temp% C:\DOCUME~1\ADMINI~1.000\LOCALS~1\Temp C:\>echo %tmp% C:\DOCUME~1\ADMINI~1.000\LOCALS~1\Temp Dan Link to comment Share on other sites More sharing options...
Steve3 Posted September 20, 2006 Author Report Share Posted September 20, 2006 FWIW, they are still on the C: drive. Guess the temp/tmp location wasn't the issue, as one of the recatalogings enabled it to groom, and it's groomed every weekend since then. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.