Jump to content

tbr00

Members
  • Posts

    38
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by tbr00

  1. Yes it is the backing up from directly mounted NTFS disk which is the confirmed bug on MacOS Monterey. Regarding the platform change, your plan is exactly what I am doing.
  2. Support has just confirmed this is a bug. It apparently only affects MacOS Monterey.
  3. One time move. So my plan now is to retain all the existing backup sets as read only for archival purposes because I know I can reliably restore from them on the Mac, and start all new for current backups and going forward.
  4. Those external disks are just a minor annoyance, not a serious issue. Its the 10's of TB of data on the NAS devices that is the issue, particularly as I have just spent weeks consolidating all my backup sets and transferring everything to new media to be sure I'm 100% secure before making this move. I agree the metadata is the problem, but it's not as simple as Retrospect support suggested. I made a simple test share with just a handful of files guaranteed not to change and backed it up on Windows. I then transferred the catalog to MacOS and as expected it decided it needed to back up everything again. Since I had not had an answer from Retrospect support as to whether there was a debug setting that would show why the individual files were miss-comparing I did Option Command Comma and turned all the logging options to max. While that gave me a voluminous log during the matching phase I could still find nothing in there showing the individual file comparisons failing. Just to eliminate any problem with the catalog, I deleted it on the Mac and recreated it from the tape. The new catalog file was a different size from the Windows created one, but it did not change the behavior. So I let it go ahead and back up everything. I now have two sessions on the tape, one from Wiindows and one from Mac. On Windows if I do Find Files and browse the session contents it's not much help because all it shows are the dates the files were backed up - pretty much redundant since that's clear from the session date, but on the Mac the view is much more helpful as it shows explicitly: filename, size, creation date and time, and modification date and time. And they all agree perfectly - so if the operating systems are giving different file metadata to Retrospect as support claims, is is somehow changing them back to being the same! Then it hit me, because the report on session contents is similarly more informative on the Mac. It shows for each session the operating system version and the file system type. For the Windows version it shows the file system as "Volume", "NTFS", with the Machine as "Local" (where in fact it's an SMB mount from the NAS), but for the Mac it says "Client volume", "SMBFS" even though there is no client machine (in the Retrospect sense) involved - it's the same NAS share mounted by SMB on the Mac. So clearly Retrospect is conservatively deciding that if the file system type is different it should not assume the data is the same even though all the other metadata matches. The documentation and Retrospect support could be clearer on this point. It is just possible the difference is because there are two different versions of SMB involved here. Windows 7 is using version 2.1 where the Mac is using 3.1. I do not know if it is possible, or if so how, to restrict the Mac to mounting with 2.1, but even if that were to fix it, I would not consider it a good solution since it would be locking in an obsolete protocol. And it seems unlikely this is the root cause anyway or everyone would have run into the same problem when just upgrading from Windows 7 to Windows 10 which I believe also uses SMB 3. More tapes ordered 😞
  5. As expected, connecting it to either a PC or a QNAP NAS and exporting it with SMB works, even though I exported it read only. However, also as expected in both cases zero files match against the existing backup sets and just as with the main shares on the NAS it wants to do a full backup. I have asked support twice if there re any debug options or elevated log level which will indicate in the log why the files mis-matching, but in both cases they ignored my request on that point. I know there is a secret settings menu (at least on windows) but I don't recall how to access it, or how to change the log level. Any pointers appreciated - I have to get to the bottom of this.
  6. Well in this case I have another system at a different location (Windows environment) that I back up disk to disk. Each time I exchange the backup disk I bring it offsite and archive to tape. I agree that if I needed to restore the data it would need to go somewhere different, but that is a problem I will deal with should disaster recovery become necessary. There is data on that disk that the Mac can read without a problem yet Retrospect blows it off as not worthy of backup. I will attempt the path of connecting it to the NAS and using SMB to mount it. However I then expect to run straight into the issue I have raised in a different support ticket, namely that Retrospect on Windows and Retrospect on Mac mounting the same NAS share do not agree on the file matching criteria, so incremental backups are not possible to backup sets created on the Windows platform. Nothing matches - another story for which I should start a different thread. . .
  7. response from the support ticket: Retrospect for Macintosh is not really designed to handle data of a locally attached NTFS volumes. You would need to either format the disk as Mac OS various native formats, connect it to another computer Windows and access the volume over the network as Windows Client or plug it in a NAS device USB port and access via SMB or AFP protocols (ADD+ >Share>>). Seems to me this needs to be made explicit in the documentation. The OS can access it so why can't Retrospect?
  8. The documentation certainly implies it should since it is accessible in the finder. Retrospect on Windows certainly has no problem backing up this same drive. I did open a ticket yesterday, but no response so far.
  9. "Mac Studio" is the hostname not a drive and selecting that just shows the mounted volumes. The main drive (ie boot drive) is Macintosh HD (SSD), formatted just as apple provided it, and mount tells me: /dev/disk3s5 on /System/Volumes/Data (apfs, local, journaled, nobrowse, protect) According to disk utility the partition map is guid. The external USB drive which Retrospect cannot see is: ntfs://disk4s1/Backup B on /Volumes/Backup B (lifs, local, read-only, noowners, noatime) In disk utility "Partition" is greyed out for this one.
  10. Yes, that's what I expected. No sign of it. Screenshot below, together with what I see in the Finder. It shows in the file system as /Volumes/Backsup B and it is fully accessible.
  11. Retrospect 18.5.2 on MacOS 12.3.1 I am setting up a new Retrospect environment having switched from Windows to a MAC and finding the user interface a little unfamiliar. I have an external USB drive on the system that I want to be able to back up. It is mounted and fully accessible in the finder, but it is not showing up in the list of available sources in Retrospect. Is there a way to manually add a local source? What I currently see are just two Local sources: Macintosh HD Recovery If I click the "+" button there does not seem to be an option to add locally connected drives.
  12. Update: I did a catalog rebuild from tape starting at member 15. I stopped it after the single member, so that gave me a catalog of members 1-15. The Backup Set Transfer then worked without a problem, so I am now running the rebuild from Member 15 to Member 36. Hopefully problem solved. Further update: Success!
  13. Retrospect 17.5.2.103, Windows I have an old archive tape backup set which I am trying to transfer to new media for preservation. The original set was created in 2010 with a much earlier version of Retrospect. I'm not certain, but it most likely was version 7.6. I want to make two copies on new (denser) media so I decided to do a tape to disk transfer first so that I would then be able to make the two copies from disk to tape without having to read all the old tapes a second time (there are 36 members). All was going fine until part way through member 15, which reported the error: Can't access session 9/29/2010 3:18:18 PM, error -2249 (could not find session) At that point the transfer stopped and it started verification of the destination disk backup set. When the verification completed, Retrospect triumphantly declared "Execution completed successfully", even though more than half the source backup set was not transferred. I looked at the session contents of the source set and indeed there is no session listed for this exact time. There are two which closely bracket it and I know they were laid down consecutively by a single script with multiple source volumes. Obviously the catalog is corrupt in some way. A second attempt at the transfer matched all the sessions already transferred with no files to transfer and without requesting a tape to be loaded, and then failed with the same error message. I tried temporarily marking member 15 as missing in the hope the transfer would continue from 16, but no luck, it still stops at the same point. I tried a catalog repair, which requested the last member of the set, and while it completed OK it had no effect on the problem. I tried the "rebuild from tapes" option, but that asks for the "most recent member", which I assume also means the last. This time it read the full tape then asked for the next member if there was one. Since there wasn't I selected Done and it finished. Still no effect on the problem. I wouldn't expect there to be really, since how can starting from the last member fix a problem that is clearly associated with a much earlier member? There does not seem to be an option to explicitly start the rebuild from an earlier Member. What is the best way to proceed? If I give the rebuild operation member 15 (or perhaps 14?) instead of the last will it go forward from there to the end of the set? Or must I start right from 1? Any guidance from those more experienced would be appreciated.
  14. Case opened with support. They are saying it does look appear to be a bug. The first recommendation to complete the verification was to start a verify, insert the member following the defective one, then click Proceed. But I can't - the Proceed button is still greyed out in that situation.
  15. Retrospect 17.5.2.103 on windows. I am running a Verify Media on an LTO tape backup set. There is a bad member and Retrospect reports multiple error 206: Trouble positioning: "8-Fileserver F" (132174), error -206 (drive reported a failure: dirty heads, bad media, etc.) Trouble reading: "8-Fileserver F" (132174), error -206 (drive reported a failure: dirty heads, bad media, etc.) always with the same 132174. After 4 repeats of the above the verify quits. How do I verify the remainder of the members? I tried marking the bad tape "Missing", assuming that Retrospect would then skip that member. However, when I try to verify again it wants to start at the beginning. I tried temporarily setting all the earlier members Missing also, but it still asks for the first member. The popup dialog window says "If tape is unavailable, please click Choices." But there is no Choices button. All I have is "Stop". The "Proceed" and "Eject" buttons are greyed out (because there is no tape loaded). Where is the "Choices" button? This seems like a bug - it asks me to click a button which it does not present. Also, if a tape has already been marked as Missing why is the Verify Media even asking for it? I am assuming that if I mark the bad tape Missing I can run a new back up and pick up anything which is lost but which is still on the source, but how can I verify the remaining members beyond the failed one?
  16. I have found one thing which I think may be relevant. When I backed up the errant partition using SMB1 the log had: 2/19/2020 5:37:00 PM: A custom selector was used to select 285,888 files out of 285,888. 2/19/2020 5:37:02 PM: Copying: 256,935 files (6.4 GB) and 28,953 hard links but with SMB2 it has: 2/20/2020 3:27:23 PM: A custom selector was used to select 285,888 files out of 285,888. 2/20/2020 3:27:26 PM: Copying: 285,888 files (6.6 GB) and 0 hard links Most of the data in this share did originally come from a UNIX system, and it would appear that SMB1 preserves the hard links in some form, whereas SMB2 is presenting them as distinct files . . . None of my other shares reported any hard links with SMB1.
  17. Progress! I found enough posts in the ReadyNAS forums to suggest the "experimental" SMB2 support in OS 4 is in fact reliable, so I enabled it. Regular access to the shares is fine from both the MACs and windows with the one caveat that for some reason on Windows, the NAS no longer shows up under "Network" in the explorer, at least not until I type its name into the address bar, at which point it and all the shares on it show up right away. smbutil on the MAC now says it's using SMB2.02. I reset the Retrospect security options back to the defaults, recycled the scratch backup set and ran a full backup of the problem share, and . . . zero compare errors. Just to be sure, I recycled the backup set again and did it a second time to make sure it was not a fluke. Again zero compare errors. I will wait till I have run a full backup on all the other shares which did not cause a problem with SMB1 and Retrospect 16 in order to be absolutely sure, but at this point I think this change has solved it. There does of course remain the issue of why this only showed up after switching from Retrospect 12 to 16, but that is something I think only Retrospect are going to be able to get to the bottom of, and I will update my Support ticket with this new information. Thank you two gentlemen for all the help, and my apologies to DavidHertzberg for miss-typing his handle earlier 🙂
  18. The 4 security options were set as: (checked) Back up file security information from servers (unchecked) Back up file security information from workstations (checked) Back up folder security information from servers (checked) Back up file security information from workstations which according to the documentation are the defaults. I don't remember ever changing any of these and they are set that way in all my scripts. I unchecked them all and ran a full backup. Once again miss-compares, but once again a different number (this time 96126) and different files. Nigel, smbutil on the MAC confirms it is SMB1. While it is possible there could be a peculiar filename somewhere, there is nothing odd about any of the filenames Retrospect explicitly lists for the first 21 miss-compares in each run. I have considered the OS upgrade to version 6, not least because a factory reset is required to expand the volume further on version 4. But as you say that's too risky without 100% confidence in the backup. In fact the whole reason I upgraded Retrospect from 12 to 16 and then started a new backup set was in preparation for going that path.
  19. OK, so I go back to a new backup set and run the full partition backup again, and I am back to a huge number of miss-compares, (183263) which is comparable to but not the same as I had before, and further the first 21 miss-compares (which is all that's explicitly listed in the log) are not the same as the first 21 the last time I did a clean run. In answer to some of the other questions: I can say with confidence nothing else has been accessing this partition between these various retrospect runs. But there is activity on other partitions on the same NAS. Second as far as I can tell the NAS is serving SMB1. Next I will experiment with the permission options.
  20. Thank you for all the useful suggestions which I am working though. First off I used ctrl-alt-P-P to change the logging levels and I found that setting "Trees and Volumes" to 7 gave some additional output in the log. First it explicitly listed every file that failed to compare rather than just the first 21, and second, for each file I have an entry: TPCFile::BackupReadOpen: OriginalFilePath = \\FILESERVER\orion\<path/filename> TPCFile::BackupReadOpen: ppath = \\FILESERVER\orion\<path/filename>, isDedup = 0 TPCFile::BackupReadOpen: \\FILESERVER\orion\<path/filename> BackupParseStreams: stream header read: (dsi. 256 256) 0 3 2 152 0 BackupParseStreams: stream header read: (dsi. 256 256) 0 1 0 15,807 0 BackupParseStreams: stream header read: (dsi. 256 256) 1 0 0 0 0 bkstreamParseRead: id = 3, flags = 0, size = 128, name = bkstreamParseRead: id = 1, flags = 0, size = 15,807, name = bkstreamParseRead: id = 0, flags = 1, size = 0, name = File "\\FILESERVER\orion\<path/filename>": didn't compare but to the untrained eye at least there is still nothing there that is helpful. Next in order to speed up experimenting I defined a sub-volume pointing to a directory containing just one file from the list of persistent failures. When I ran the backup on that sub-volume, as expected, it then wrote just the one file to tape, but that file then verified OK. So it cannot be related to the attributes of the individual files. Just to be sure nothing else had changed I ran the backup of the full partition again expecting to see one less than the prior number of persistent failures (119231) but to my surprise it this time only found 6900 files it said it needed to write. So it seems that when I had the logging level turned right up, a large number of the files must have compared OK. I could not tell the actual number of failures because the voluminous output overran the depth of the log file (I have now increased the maximum size). And on this pass now all 6900 files verified OK. So retrospect now thinks the backup is complete. I am starting a full backup after recycling the scratch backup set to see if it reproduces the original problem . . .
  21. DavidHerzbeg is correct. Retrospect is running on the windows machine, which has partitions mounted (CIFS) from the Netgear Readynas. The macs are not involved in this issue. I did not include the log file originally because all it contains (see below, with paths/filenames elided) is the fact that a bunch of files failed to compare. In my original posting instead I asked the question: "Is there any way to get more information from the logs as to why it thinks these files are failing to compare?" In the hope that someone could tell me how to get Retrospect to write more detailed information to the log when it fails to match to get some insight as to the real cause. I have now opened a support ticket with Retrospect and will report further if it leads to a solution. Thanks for the help. From the logfile: - 2/14/2020 8:17:31 AM: Copying orion on Fileserver 2/14/2020 8:32:45 AM: Found: 285,888 files, 9,651 folders, 6.6 GB 2/14/2020 8:32:48 AM: Finished matching 2/14/2020 8:32:49 AM: A custom selector was used to select 285,888 files out of 285,888. 2/14/2020 8:32:52 AM: Copying: 119,232 files (1.4 GB) and 0 hard links 2/14/2020 9:15:22 AM: Building Snapshot... 2/14/2020 9:15:22 AM: Copying properties for 9,651 folders 2/14/2020 9:16:34 AM: Finished copying properties for 9,651 folders and 0 files 2/14/2020 9:16:36 AM: Copying Snapshot: 2 files (60.9 MB) 2/14/2020 9:16:41 AM: Snapshot stored, 60.9 MB 2/14/2020 9:16:41 AM: Comparing orion on Fileserver File "\\FILESERVER\orion\<file1>": didn't compare File "\\FILESERVER\orion\<file2>": didn't compare File "\\FILESERVER\orion\<file3>": didn't compare File "\\FILESERVER\orion\<file4>": didn't compare File "\\FILESERVER\orion\<file5>": didn't compare File "\\FILESERVER\orion\<file6>": didn't compare File "\\FILESERVER\orion\<file7>": didn't compare File "\\FILESERVER\orion\<file8>": didn't compare File "\\FILESERVER\orion\<file9>": didn't compare File "\\FILESERVER\orion\<file10>": didn't compare File "\\FILESERVER\orion\<file11>": didn't compare File "\\FILESERVER\orion\<file12>": didn't compare File "\\FILESERVER\orion\<file13>": didn't compare File "\\FILESERVER\orion\<file14>": didn't compare File "\\FILESERVER\orion\<file15>": didn't compare File "\\FILESERVER\orion\<file16>": didn't compare File "\\FILESERVER\orion\<file17>": didn't compare File "\\FILESERVER\orion\<file18>": didn't compare File "\\FILESERVER\orion\<file19>": didn't compare File "\\FILESERVER\orion\<file20>": didn't compare File "\\FILESERVER\orion\<file21>": didn't compare and 119,211 others 2/14/2020 9:57:41 AM: Execution completed successfully Completed: 119232 files, 1.4 GB Performance: 32.4 MB/minute (31.8 copy, 33.1 compare) Duration: 01:40:10 (00:17:03 idle/loading/preparing)
  22. No OneDrive, but the partitions are on a Netgear ReadyNas. I have not seen a similar issue backing up the local drive, but there is not much data there, so I can't be sure it does not happen in that case. Regarding Windows 7, all our other machines have been upgraded to Macs but I keep this one around because it has a bunch of old hardware devices (not least my tape drives) which I cannot easily move to a Mac. Extended security updates for Windows 7 are available to 2022.
  23. I have just upgraded from Retrospect 12 to Retrospect 16 on Windows 7. I started to create a new backup set, on LTO4 tape with full verification, but I am getting "File didn't compare" errors. For example, in one partition, out of 288285 files written 119232 did not compare. I ran the backup again, and Retrospect decided these 119232 files needed to be written again, and did so, but again all 119232 failed to compare. I extracted both copies of one of the files from the tape and manually compared it to the source and all three versions are identical, so they appear to be written correctly but for some reason not comparing. This partition had previously been backed up without this problem with Retrospect 12 on a different backup set. Is there any way to get more information from the logs as to why it thinks these files are failing to compare?
  24. I figured it out - and it's a little embarrassing. When I came to transfer manually the additional snapshots I discovered that the Snapshot Transfer window somehow had a selector set, presumably from some long past activity. That selector said to exclude files with "volume name matches c". Now at first sight I though that was harmless because nothing had originally come from C:, but of course it's not a complete match, but matches anything containing the string "c". Sure enough all the sources which transferred zero files contained the letter c in the volume name. With that selector deleted, things are looking up. Thanks Lennart_T for the help.
×
×
  • Create New...