Jump to content

External USB drive missing from sources


tbr00
 Share

Recommended Posts

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.

Link to comment
Share on other sites

"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.

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

2 minutes ago, tbr00 said:

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?

It would not make much sense in backing up a volume you can't restore. The OS (and/or Retrospect) can't write back any information, making the backup useless.

There are no official documentation from Microsoft how NTFS really works. That's probably why Retrospect for Mac will not handle it.

Do you really need it to be NTFS? I would recommend exFAT, which Windows and macOS handles just fine. Retrospect for mac and Retrospect for Windows handles it as well.

Link to comment
Share on other sites

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. . .

Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

It is the metadata that makes the files look different to Retrospect.

Some years ago a co-worker had a Windows computer with three hard drives: An XP boot drive, a Vista boot drive and a data drive.

When booted into XP, all files of the XP disk and the data disk was backed up (as expected).

When booted info Vista the entire data disk was backed up again, since the different Windows versions displayed a different set of metadata to Retrospect, making Retrospect to believe it was different files.

When booted back into XP, (only) the files that had changed on the data drive since the last XP backup was backed up. Similar with the Vista backup: The files on the data drive that changed since the last Vista backup was backed up.

 

Why do you want to backup your external drive from both Windows and Mac?

I would have it always connected to a Windows computer, install the Retrospect Client on the computer and backup from your Mac running Retrospect.

If that won't work for you, please elaborate on your setup, what you want to do and why you want to do just that. :) 

Link to comment
Share on other sites

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 😞

Link to comment
Share on other sites

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.

 

  • Thanks 1
Link to comment
Share on other sites

On 4/25/2022 at 8:50 PM, tbr00 said:

Support has just confirmed this is a bug.  It apparently only affects MacOS Monterey.

For clarity -- which? I assume the "backing up the directly-mounted NTFS disk". but just want to be sure...

On 4/20/2022 at 3:52 PM, tbr00 said:

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.

I don't know if that's what's actually going on, but in general Retrospect (like all good backup software) makes the not-unreasonable assumption that "if there's any doubt, back it up again". In the vast majority of cases it much better to "waste" resources doing that than to find that the latest version of "My Very Important File.doc" can't be restored because, well, it kinda looked the same as the last one so RS didn't bother...

Where it does bite is this kind of platform move. Having been there myself, I feel for you! What I do these days is start new sets on the new platform, run old and new in parallel until new is up to date, then archive the old in case it's ever needed.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...