Error -2,265 during grooming

[ByTheC]

My backup media is getting quite full so I attempted to groom previous backups in order to free up space. Retrospect noted the execution was incomplete due to a -2,265 error (Archive file is missing File record). The suggested fix was to recreate the Backup Set's Catalog File. Only problem is, I had recreated the Catalog File successfully the day before running the groom operation.

I checked the Knowledge Base, but the only entry I found about error -2265 says "These are a side effect of performance-optimized grooming and are only cosmetic. The log messages do not indicate that there is an issue with the backup set." This particular media set is configured for Storage-optimized grooming however and there would appear to be some issue of some kind as the grooming operation doesn't actually reduce used space on the backup media, instead indicating an error.

Is there a way to resolve this?

 

[Retrospect 15.6.1 Mac running on MacOS 10.14.6 (Mojave)]

Catalog_rebuild_log.txt

Groom_fail_log.txt

[Lennart_T]

Although I have not experienced that particular error, I think grooming is much more stable in the current version of Retrospect (17.5.x).

[DavidHertzberg]

ByTheC,

Let's consult the cumulative Retrospect Mac Release Notes.

First, notice that the Knowledge Base article you cite was last updated 1.5 years before your version 15.6.1 of Retrospect Mac was released.  It's by no means inconceivable that in that time period error -2265 was expanded to cover another error.

Second, WRT what Lennart_T posted, notice that in release 17.0.0 "Grooming: Fixed issue where groom failure could cause catalog errors after a rebuild (#8457)".  Is it possible you did another grooming run before you recreated the Catalog File on 1/26/2021?

P.S.: Nigel Smith, in the first sentence of his post directly below, shows that his recall is excellent.😀 See the last sentence of the Note near the bottom of page 186 of the Retrospect Mac 16 User's Guide.

Edited February 2, 2021 by DavidHertzberg
P. S.: Nigel Smith, in his post directly below, recalls _correctly_ that Fast Catalog Rebuild can only be used on Disk Media Sets when grooming isn't turned on.

[Nigel Smith]

Logs show a Fast Catalog Rebuild and, IIRC, that can only used on Disk Media Sets when grooming isn't turned on. Perhaps you are falling foul of turning on grooming too late, after the (default) Fast Catalog Rebuild format has been used? Have you groomed that set previously? Are you using the set's builtin options or are you running a separate script?

[ByTheC]

Thank you all for your responses, my replies:

 

@Lennart_T: Noted, thank you. I haven't upgraded beyond 15.6.1 up to now as its feature set was working for my needs, but it may be time to reconsider.

@DavidHertzberg: Understood about error -2265 possibly expanding in scope beyond what is noted in the Knowledge Base. It was all I had to go on when I researched possible causes, any new scope of what triggers that error message hasn't been entered into the Knowledge Base...yet. Also yes, I had attempted a grooming pass on 1/15 that also failed, with the same note in the session log about needing to rebuild the Catalog File. So the next time through on the 25th I did the Catalog File rebuild first and then the groom, only to have it fail for exactly the same reason.

@Nigel Smith: I puzzled the Fast Catalog Rebuild notice in the log as well. To my knowledge, this Disk Media Set has always had grooming turned on since it was originally defined. That was a couple of years ago now so I may be remembering it wrong though. The User's Guide makes it sound like Fast Catalog Rebuild is a software toggle of some kind, however my UI doesn't reflect this term at all under Media Set/Options tab, even as a part of the UI that is greyed out/not changeable (but at least shown).

My question for the group is: where do I go from here? My fundamental problem of running out of backup storage space still exists. Regardless of the release version of Retrospect running, it would appear (to me at least) that something is amiss with the way the Media Set is configured, or with the way Retrospect thinks it's configured. If there's a slower, more laborious way to rebuild the Catalog File than the Fast Rebuild the application is defaulting to, that ultimately allows the grooming to occur, I'm willing to sit through however long it takes to rebuild 10+ TB. If the upgrade to 17.5.x is the fix, I will happily buy in. Thank you all in advance for your time and consideration.

 

Respectfully,

Andre

[Nigel Smith]

On 2/3/2021 at 5:37 PM, ByTheC said:

The User's Guide makes it sound like Fast Catalog Rebuild is a software toggle of some kind, however my UI doesn't reflect this term at all under Media Set/Options tab, even as a part of the UI that is greyed out/not changeable (but at least shown).

As of RS v13(? -- David will know) Fast Catalog rebuild is always "on" for Disk Media Sets unless you enable grooming, and then it's "off". In v17, and maybe before, it isn't even shown as an option, but I suspect the UI took time to catch up with the behavioural change and they disabled the option rather than making a new layout.

Which is why I was asking if you'd enabled grooming after the rebuild. It may just be that the logs are mis-reporting on that line.

What I don't understand is your first sentence:

On 1/31/2021 at 7:28 PM, ByTheC said:

My backup media is getting quite full so I attempted to groom previous backups in order to free up space.

As I understand it, grooming via Media Set options is either off, to a set number of backups, or to a defined policy -- not much scope for you triggering grooming yourself. So how did you do this? That may have a bearing on the matter.

I'd also try doing the rebuild then backing something up to that set, even just one small file, before the grooming operation.

Other questions: How much free space do you have on the system disk? Where is the 10TB+ of data stored, and how much free space is there on that? When was the last time you disk-checked it? Rebuild log says RS is skipping a file -- check that on your disk media, can you replace it from eg tape. Same for the files mentioned in the groom log.

It might also be worth downloading the v17 trial, maybe on a another machine, and trying the rebuild on that. If successful you might even (I haven't tried it!) be able to copy the new catalog back to the v15 machine and use it there -- you can move catalogs up versions, but I've never tried down! If you can't but the rebuild worked, at least you'll know upgrading to v17 is one way out of your problem.

[ByTheC]

I thought grooming was an automatic process as well, meaning my understanding was I shouldn't have to babysit the process, it would just do its thing. But my storage media kept filling up (it's at 93% now) and it appeared that grooming was either not running automatically or I had configured it wrong and it was running automatically but not freeing up any space due to my snafu. So I selected Media Sets on the side rail, selected the Media Set for my backup in the main window and then used the UI button about 3/4ths of the way to the right above the main window that is labeled Groom to launch the process.

The system disk is not my backup target, instead this backup goes to a Synology NAS, total capacity 10.8 TB. It has scheduled consistency checks on the array that run, the latest pass was completed 1/14 with no errors reported. I don't have any offsite or archived offline storage beyond what is on the NAS due to the capacity involved. I can locate the "skipped" file noted in the rebuild log in the Finder, but since it's a .rdb file there's not much the OS can tell me about it, besides its size (200.5 MB, not zero as the log indicates). The two files mentioned in the groom log also show in the Finder with hundreds of megabytes of file size, again beyond that information there's not much I can do about validating them as I'm extremely reluctant to run a non-Synology file system check on my 10 TB array.

I will take your suggested next steps: a Catalog File rebuild, followed by a small file update, followed by a manually invoked groom to see if that turns out any differently. If not it may be time to upgrade to v17, but my only concern there is the Media Set (Synology NAS) used for my backups is already defined, if maybe incorrectly with respect to the grooming options. Ultimately I'd like to remove some older backups to free space but would rather not have to start from zero with a fresh Media Set or catalog file, losing any kind of historical restore options. Maybe v17 has tools to fix this issue without starting over, that's my hope at least if it comes to that.

Many thanks for your input and helpful suggestions. I will advise what the outcome is.

Respectfully,

Andre 

[Lennart_T]

7 minutes ago, ByTheC said:

I thought grooming was an automatic process as well

It is, but only "sort of".

When you create a disk media set, you specify how much of the disk it can use. When the ongoing backup is going to reach that limit, a grooming process starts. That happens in the middle of a backup and can take hours. That means the completion of the backup can be delayed by hours.

For that reason, it is advised to schedule groom scripts every once in a while. I suggest once every Saturday or Sunday.

[Nigel Smith]

2 hours ago, ByTheC said:

and then used the UI button about 3/4ths of the way to the right above the main window that is labeled Groom

I had completely forgotten about that button! Probably because it's always dimmed for me...

2 hours ago, ByTheC said:

The system disk is not my backup target, instead this backup goes to a Synology NAS

Ah... Grooming a set stored on a NAS is an absolute shedload of network traffic, especially in storage-optimised grooming. See the "Grooming Tips" page, section 11. Do everything you can minimise problems, ideally (if possible) setting up a short-cabled direct connection from your Mac to the SAN -- you may want to use different interfaces on both machines and hard-code the IP addresses if you normally use DHCP. And make sure there's no scheduled processes on either machine that might interfere.

Since the Synology checks OK, try copying the "bad" files to your Mac -- if that works and the "bytes" size shows the same in Finder's Get Info, it's even more likely that there was a network glitch. Experience has shown that RS is a lot more sensitive to such things than eg a Finder copy, so a NAS connection that seems OK in normal use can be too flakey for a "big" RS operation.

[ByTheC]

Second attempt with the same results. Catalog file rebuild was successful, attempted groom after a small backup was not. RS .rdb files noted in the log files for both operations were copied to system/boot disk. File AA001312.rdb flagged during the rebuild as zero data bytes reported indicates 200.5 MB in the Finder for the system disk and NAS copies. File AA008645 flagged during grooming with error -1101 (file/directory not found) was located on the NAS and copied to the system disk where the Finder reports a 158.4 MB file, agreeing with copy on NAS. File AA008658 that generated our favorite error -2265 (Archive file is missing File record) shows 614.7 MB on the system disk copy (agreeing with the NAS copy), beyond that I can't peer into the file itself to see what the internal structure is or isn't with respect to RS.

I guess at this point I need to upgrade to v17.5.x and hope that fixes this issue unless the group has any other suggestions.

Thank you all for your time and insight. Retrospect is very fortunate to have such technically adept people monitoring these forums and replying to questions like mine.

Warmest Regards,

Andre

GroomFail_2.txt

Rebuild_2.txt