Jump to content

tbr00

Members
  • Content count

    22
  • Joined

  • Last visited

Community Reputation

0 Neutral

About tbr00

  • Rank
    Newbie

Recent Profile Visitors

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

  1. tbr00

    File compare problem

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

    File compare problem

    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 🙂
  3. tbr00

    File compare problem

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

    File compare problem

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

    File compare problem

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

    File compare problem

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

    File compare problem

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

    File compare problem

    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?
  9. 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.
  10. As mentioned in the original post I was transferring 34 snapshots. I am now pretty much doing as you suggest, except starting with a full backup from disk of those partitions that are still online. Now that's complete I am about to manually add the remaining snapshots I need. Given there was no error reported in the original attempt, there has to be a bug. Either an error did happen, but it was not reported, or, it simply didn't function as advertised. My money is on the latter.
  11. Transfer was from LTO-3 tape to LTO-4 tape.
  12. Retrospect 12.6.1.101, Windows 7 Professional. I have a tape backup set that I wished to transfer to new media. However, the source tapes contain one particularly large snapshot which is no longer relevant. So, instead of copying the entire backup set with the Backup Set Transfer function I used the Snapshot Transfer function. I added all the snapshots except for the one I did not require to the source set catalog file, selected them all, and initiated the Snapshot Transfer operation. The operation completed without errors. 34 snapshots were selected and transferred. However, I noticed in the logfile that for some sources. while I had selected all available snapshots on the source tapes for that source, Retrospect decided that for each of these snapshots "No files need to be transferred". Since there is no overlap in the files in these snapshots and those from the other sources on the source set, and since the destination was new media, something had to be wrong. Here is an extract from the log: Pictures (10/26/2017 9:40 AM) No files need to be transferred 5/8/2018 8:33:05 PM: Execution completed successfully Duration: 00:00:19 (00:00:11 idle/loading/preparing) Pictures (9/16/2016 9:14 AM) No files need to be transferred 5/8/2018 8:35:43 PM: Execution completed successfully Duration: 00:02:38 (00:02:30 idle/loading/preparing) Pictures (7/28/2016 11:36 AM) No files need to be transferred 5/8/2018 8:36:33 PM: Execution completed successfully Duration: 00:00:50 (00:00:42 idle/loading/preparing) If I look at the destination set there are no "sessions" recorded for these transfers but there are snapshots. However, if I try a restore, I can select any one of these snapshots, but it contains zero files. The files are most definitely there on the source backup set and I can restore from them as expected, so they should have been transferred. Clearly something is seriously wrong here.
  13. I cannot do a tape verify in 7.7 build 325. Windows XP, IBM Ultrium 2, SCSI I have two failing scenarios. The backup set I want to verify is missing member 2. When I run the verify it completes the first tape OK, but does not eject it. It then asks for member 2, even though that is marked missing in the backup set. I click choices, tell it is missing again, then it asks for the third member. But, as soon as I touch the eject button on the drive to switch tapes Retrospect exits. No message, nothing in the log, just gone. This is repeatable. Then I tried a run ejecting the tape before telling it member 2 is missing. This time, when I press the eject button Retrospect crashes with Assertion failure at: "elem.cpp-1098". I submitted the error report it created.
  14. tbr00

    Disk to tape problem

    Thank you! If I define it as a subvolume and just backup that subvolume it works. Backing up the whole volume still behaves as before though, ignoring the Retrospect directory. At least this gives me a way to get what I need.
  15. tbr00

    Disk to tape problem

    I have 7.7.203 with driver 7.7.1.102 I have a number of client machines backed up automatically to disk backup sets stored on a share on a NAS device. I backup the whole NAS to tape. For some reason Retrospect is not backing up to tape anything in the "Retrospect" directory where the disk backup sets are stored. I have tried a separate immediate tape backup in which I set the source to the share containing the Retrospect directory and I made sure the filters said to include "everything" and exclude "nothing" yet still it does not copy them. If I use the check function to see what files have been selected by the selectors, the Retrospect directory is shown, but the box is not checked, and I cannot check it by hand. Why will Retrospect not treat these files as just files and back them up? How can I be sure these are the only files it is arbitrarily choosing to ignore?
×