Jump to content

tbr00

Members
  • Posts

    38
  • Joined

  • Last visited

  • Days Won

    2

tbr00 last won the day on April 25

tbr00 had the most liked content!

Recent Profile Visitors

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

tbr00's Achievements

Apprentice

Apprentice (3/14)

  • Dedicated Rare
  • First Post Rare
  • Collaborator Rare
  • Conversation Starter Rare
  • Week One Done Rare

Recent Badges

2

Reputation

  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.
×
×
  • Create New...