Jump to content

ByTheC

Members
  • Content count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ByTheC

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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
  2. 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
  3. 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
  4. 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
  5. David, Many thanks for your help. It took a while to rebuild, but the next backup ran perfectly after. Good Health to you, -Andre
  6. Background: I have 2 Synology NAS's, one that is strictly the storage for my media (photo) files, the other is the main backup destination for the media drive as well as other local drives in my system. For reasons unknown, no software changes of any kind made in over a year, the media NAS began to experience errors and crash when Retrospect (v 15.6.1 for Mac) ran its daily backup script. Synology support suggested changing the mounting of the media NAS from AFP to SMB. I did this and it seemed to fix whatever issue was at play with the media NAS crashing. I had to add the SMB media NAS share to my Retrospect backup script, which regarded it of course as a "new" drive and began to back it up in its entirety. During this process I discovered that due to operator error on my part the grooming options on the backup NAS hadn't been enabled and it began to run out of space. Retrospect prompted me mid-backup to add a new member to the Media Set that formerly consisted of the backup NAS only. I selected a local disk drive as a stopgap measure. After the backup was complete I enabled the grooming options on the backup NAS so that it should not run out of space in the future. The issue that I now find is that I need to remove the disk drive I added as a stopgap, and can't find any way to do so. I've looked through the manual, adding a member to a storage set is covered, removing a member is not. I've marked the stopgap drive as "lost" within Retrospect, but now the Activity pane shows each daily backup with a red 'x' for an execution error because of this. I have to look at each days' backup log to determine that the only error is the lost drive and nothing more, ideally I'd like to return to each backup pass being reported with the green check so that any real errors stand out and a quick glance at the Activity pane is all that's required. Is there a way to accomplish this without losing the groomed backups already present on the backup NAS? I don't have enough local storage to temporarily cache the backup NAS (~9.6TB) nor the media NAS (3.7TB) so need an in-place solution if possible. Thank you in advance, Andre (Retrospect 15.6.1 for Mac, MacOS 10.14.6 [Mojave])
×