Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. DavidHertzberg

    Assertion failure at elem.cpp-1096

    sowen222, According to the head of Retrospect Tech Support, "Fast Catalog Rebuild is turned on by default with all Disk Backup Sets. We don't have an option to turn it off/on because it is always enabled." Again according to the same person, "The .session files help Retrospect perform faster catalog rebuilds. We made the changes to help cloud backup users with catalog rebuilds. [new paragraph] Retrospect will read these files during a rebuild process. If you want to perform a through rebuild, you can delete all .session files before catalog rebuild and Retrospect will create new .session files from the original backup set data." I suggest that you file a Support Request, specifying a Feature Request that a Thorough Catalog Rebuild option be added to the "Recreating a Disk Catalog" dialog that is now shown and discussed on pages 453-456 of the Retrospect Windows 15 User's Guide. That option would delete all existing .session files and create new ones. The code for doing that used to be the default for the operation up until Retrospect Windows 11. 
  3. Yesterday
  4. sowen222

    Assertion failure at elem.cpp-1096

    @DavidHertzberg Thanks for your reply, I was intending to update this post. I had contacted Customer Support, and they suggested a 'thorough rebuild' of the catalogue... I think that option used to be available in previous versions of Retrospect, but now it appears you have to go into the Backup Set folder and delete all the ".session" files, then do a rebuild, at which point Retrospect does the thorough rebuild (instead of the usual quick rebuild). The Retrospect for Windows documentation has not been updated recently, because there the 'fast rebuild' as a check-box (Retrospect v12) is still documented, and there's nothing about deleting the '.session' files to force a thorough rebuild. In any case, the rebuild detected broken chains in a number of files which had been backed-up in 2017 using block-level incremental, and it corrected the corresponding snapshot entries in the catalogue. After that, the transfer completed successfully. A bit drastic that Retrospect just dies with 'assertions' and meaningless messages, rather than giving a meaningful description and recovering gracefully, but oh well :-/. Just glad I have my backup set corrected, and for safety's sake, I've turned block-level incremental off (in my case, it wasn't resulting in a huge space saving anyway).
  5. DavidHertzberg

    Assertion failure at elem.cpp-1096

    A search of the Forums doesn't show a report of an assertion with this particular number. Here's why and how to file a Support Request. If you just upgraded to Retrospect Windows 15 you may be entitled to personalized phone support, but I understand the European Retrospect Tech Support representative doesn't know very much.
  6. Cabling my "backup server" directly to the MoCA adapter in my bedroom, which I mentioned I had done at the end of the second paragraph here, resulted in a -530 Bug 2 scenario when I booted the Mac Pro "backup server" four hours after the scheduled time for the daily Backup of my MacBook Pro this morning. That means both the "sacrificial" NoOp script and the "real" Backup script failed with -530 errors. I was then able to do a two-second Locate of my MBP, and run the "real" script manually. I have accordingly just re-connected my bedroom MoCA adapter to my Mac Pro through the 5-port 1Gbps Ethernet switch in my bedroom.
  7. Nigel Smith

    can't link to

    I'm guessing this is Filemaker Server machine running under OS X... "Content" files uploaded to your database server and linked rather than embedded -- in this case a PDF -- are backed up once by Filemaker's internal scripts and then, subsequently, linked to so that you don't waste disk space. I *think* the latest backup has the real file and the previous backups contain links, but that should be easy enough for you to check. Check the timestamps in the paths above and you'll see that the older "instance" of the file can't be linked to the newer. So either you haven't duplicated that later "instance" or, for some reason, RS can't recreate the link in the older FMS backup directory. I'd worry about the first and honestly not care about the second since if I had to roll back to an earlier version of my database it wouldn't be that much extra work to manually copy "content" files into the right place. Which is it, and what are you duplicating to? Nige
  8. My retrospect clients are flawed by this annoying behaviour too. It isn't a cosmetic flaw. Retrospect is spamming my clients system logs making logs difficult to manage.
  9. Last week
  10. 1. It did, but Multicast also did that. 2. Yes, of course. 3. As per above, when run 2 hours past the scheduled time, the "sacrificial" NoOp script failed within a few seconds with a -530 error, and immediately after that—with no manual intervention—the "real" Backup script ran fine. This is the -530 Bug 1 scenario, as I have named it, which has occurred frequently since early February 2017. 4. I followed those steps nearly two years ago. The only exception is that "Make sure the client has the most recent version of the Retrospect client software" no longer applies, because—as I stated above—going more recent than the Retrospect Mac Client 14.1 makes the "real" Backup script also fail with a -530 error—an intermittent situation which I have named -530 Bug 2. 5. As stated in the preceding paragraphs of this post.
  11. David, Let's digress... I'm assuming the client and Server now work to at least see the internet. So, did you use Subnet client selection to register your client, did it find the client? Did you (delete the old client and) re-add it to your script(s)? Did this fix the -530 error you said you get or not on an actual backup script? If not... Did you then see and try the troubleshooting steps here? What were the results of that? Henry
  12. henry-in-florida, Unfortunately it's not "very old news" when it affects what we can discuss in these Forums. I suggest you read the last two substantial paragraphs in that same post I linked to concerning the person who is the head of Retrospect Technical Support. I only have one router in my LAN, and that is my Verizon-provided Quantum FiOS "gateway". That router is directly connected to a full-up 8-port 1Gbps Ethernet switch in my study. That switch is in turn connected to a MoCA 2.0 adapter, which via a length of coax cable is connected to an identical MoCA adapter in my bedroom. Until a few minutes the adapter in the bedroom was connected to a 5-port 1Gbps Ethernet switch, but only one of the ports on that switch is in active use—connected to my Mac Pro "backup server". In order to eliminate a possible source of timing delay, I have just now cabled the "backup server" directly to the MoCA adapter in the bedroom. It works fine for a test NoOp backup; we'll see whether it makes any difference in eliminating the -530 error I got for the "sacrificial" NoOp script run two hours after its scheduled time early this morning (the "real" backup script scheduled directly after it ran fine). My LAN is totally wired. A few months ago I tried running a "real" Backup script via 802.11g (the fastest speed the wireless built into my old Mac Pro supports). It ran at around 20% of the normal speed, probably partly slowed down by the three layers of sheetrock and one concrete column between my router (a DSL one at the time) and the Mac Pro.
  13. Hi David, I stand corrected as he-whom-you will not name is in Support. I go back a long way, too. So I recognize the history lesson. However that is very old news. One that I prefer to leave in the scrum gone by. As to YOUR issue with -530 errors, switches should not cause it, since by definition, a switch doesn't assign IP ports, rather simply allows data to pass along to multiple connections paths at the proper speed between the router (which IS the only type of device to deal with the IP assignment table) and the client device(s). If, OTOH, you have multiple routers (most routers have an included switch) cascaded throughout your network, then it's a different kettle of fish. In case you have "Switches" that are really routers and wish to deactivate the router part, try bridging mode on those routers to avoid a router behind a router situation. Or you can try to use subnets there AND in Retro as you are apparently doing with the proper subnet assignments for your reconfigured system. I'd avoid the use of multiple routers for LANS, personally, as much as practical anyway. After all, do you really have 250+ devices to manage at home? I use bridging mode for devices like WAP(s), which typically have routers inside them. My network of WAPs improve wireless coverage at home, several WAP's "meshed" to appear as one. I also frequency coordinate my use of spectrum for both bandwidth and cross channel RFI (radio frequency interference) coordination in WAP RF assignment. That has worked for me prior to the advent of recently introduced meshing WAP "systems" that recently came on the market. They don't do that to the same extent as Apple did. They are now out of this market, sadly. Again, Apple was way ahead of their time on this since the Airport Express and Extreme WAP products do (and were the first to) coordinate between themselves when set up correctly on a single SSID. Some of these new type meshing devices claim very high network connection speed due to multi-channel wireless connectivity (may be false claims, since I did not notice such terrific, read claimed results when I helped set up a friend's system using one). So I'd recommend you perform some thorough testing for WAPs before using them for Retrospect. For backup speed, I still use wired LAN connections between Server and clients, not wireless.
  14. Sigh... it's that time of year again - time to clean up and archive backups - when I face major hassles with Retrospect. What should be relatively straight-forward, always turns into a multi-week drama where I question the reliability of Retrospect backups. Every year it's the same story, just different 'assertions' 😬 I have a backup set which contains weekly backups from the last two years - 2017 and 2018 - and I want to create new set (as a document archive) with only monthly snapshots and a selection of the directories/files from the original backup. I'm using the latest version of Retrospect Desktop for Windows, version 15.6.1.104. My Windows 10 workstation is completely up to date. Transferring the selected snapshots goes fine* for most of the snapshots from 2018, then I start getting assertion failures for various snapshots from 2017: Assertion failure at elem.cpp-1096 LmGet: ndex = 2 > nsp->count = 1 I recreated the catalogue (which completed without error) but I still get the assertions during the snapshot transfer. If I try to transfer just the problem snapshots to a completely new backup set, I get the same assertions. I've tried different copies of the source backup set (I have one on-site and two off-site), but they result in the same assertions. I completely un-installed (including deleting the ProgramData\Retrospect directory), and re-installed, but I get the same error. Any suggestions? *Note: I write that transferring the selected snapshots goes fine, but even some of the transfers which are successful report missing files - odd, because the files (e.g. a cache file) weren't even in the backup in the first place, and I'm not trying to transfer them anyway. For example: [!] Exsp::exspBuildPartialFileSessionList: (OnSite) can not find node path "C:\...\GoogleEarth\dbCache1.dat" in session 2017.09.06 12:47:02.789 PM
  15. Mathemagier

    Tape backup error 102 Win 10

    Hi Lennart, I already changed the HBA from Adaptec 1405 to LSI SAS9207-8i due to the same problem before. At the beginning, it worked quite well, but now, the error occured again, it's completely random, but in average 20 Min. after backup start. Firmwares of tape and card are the newest ones. Unfortunately, due to Windows 10 updates (ver 1803), there might be some impact I read here in the forum. Can this be a cause for the problem? Because I use Retrospect 12, not 15, but I am not backing up any Win10 system files, only archiving local files from a local HDD currently not in use. I have a pool of local HDDs organized logically in Drive Pool, but this have never caused trouble before. I will try a change of cables. Thanks a lot for the answer. Andreas
  16. henry-in-florida, First, the person you mentioned in the first sentence of your post immediately above has for years been the head of Retrospect Technical Support—not the head of Sales unless there has been an unannounced management upheaval. He's worked in T.S. since 1994 (and still will until at least Wednesday according to this announcement), and lived through the "near-death employment experience" I discussed in the first substantive paragraph of this post. As I discussed in the second substantive paragraph of that same post, he's IMHO a prime example of "Retrospect Inc. PTSD"—so for the last year or so I've had a policy of never mentioning his name on the Forums (because I'm convinced he does a daily search of the Forums looking for a mention of his name in a post by me). Nevertheless he's a good man doing a very difficult job, and I admire him even though I think 24 years in T.S. have made him just the least bit crabby. My intermittent -530 error problem has endured through two MacBook Pros and two pairs of Ethernet switches, so it's not a simple hardware problem. My best guess is that it's related to the fact that the switch in my study—where my two "clients" are located—and the switch in my bedroom—where my "backup server" is located—are connected via an installed-when-the-apartment-was-built stretch of coax cable with a MoCA adapter at each end. I'd love to replace that with a stretch of Cat5e Ethernet cable, but I couldn't do that without either tearing up an interior hallway floor or running a 100-foot-long Cat5e cable just underneath the ceiling of 3 sides of that hallway. At a cost of $120 I replaced the MoCA 1.1 adapters with MoCA 2.0 adapters about 6 months ago, but that doesn't make any difference. IMHO there's a bug in the Retrospect Multicast code that makes it vulnerable to timing delays, particularly when the "backup server" has just been booted and immediately needs to run a scheduled script. I even started a thread about that on the Ars Technica Networking forum, but nobody had an answer.
  17. Lennart_T

    Verifying backups on B2

    So, yes, I would do it at least once.
  18. Hi David, I should've credited Robin Mayoff, Director of Support and longtime Retro boss. He explained troubleshooting Multicast, which is a network standard, not a Retro invention. The troubleshooting procedure(Multicast app) is nice but not easy to implement, since it involves setting up a path for the client AND the server machines outside of the Retrospect app to prove it works. It clearly didn't. I found the relevant app and tested it. Sure enough, the client's port is stuck for this access, I know not why. That doesn't address what the problem is, only that it's not Retro. And it wasn't. The fact that the Server works and it's port is open. That leaves the other port on the router since subnet works and it's blocking of port for the range needed by Multicast. I could've tried to force open those ports for the IP and confirm. That would be the fix for the router- port blocking or assignments. Rather, I simply went with Plan B, e.g., Subnet Broadcast. It was easier to implement, and Retrospect engine settings support it quite well. As you apparently found as well. One day, I'll get the complete port assignment for Multicast and open a hole for all three machines' ports. Ah, one day...
  19. henry-in-florida, First, sorry for misreading your second post in this thread. I saw "The only relevant IP's are clients at .70, .64 (TWO CLIENTS), .86 (the Server)", and thought you were saying you had two clients at .64. Second, thanks for probably solving a problem I have had for nearly two years with -530 errors on Backup script runs. I wasn't having any problems with Adding my two Mac clients, but I have been intermittently getting -530 errors for the first client (a MacBook Pro) when I run scheduled daily scripts that back it up. My closest approach to a remedy has been to schedule a "NoOp" script 5 minutes before the "real" script; the "NoOp" script is a duplicate of the "real" script that adds the No Files rule. Because the -530 errors are intermittent—indicating IMHO that the error is hardware-related, sometimes the "NoOp" script immediately gets an error but the "real" script runs OK, sometimes both scripts run OK—especially when both my "backup server" and my MBP client are booted before the scheduled time for the "NoOp" script, and sometimes the "NoOp" script sits there past 3 minutes trying to Find the MBP. My cure in the latter case is to Pause the "NoOp" script, do a Locate—which always works—of the MBP, and then do a Stop of the "NoOp" script; at that point the "real" script always starts and runs OK. I long ago submitted a Support Request for this problem, and twice Retrospect Tech Support has given me test versions with extra logging so that I can help the engineers find the bug. I am permanently stuck running the Retrospect Mac 14.6.0 Engine and Console and the 14.1 Client, because the test versions indicated that engineering had introduced a "fix" in 14.6.1 that actually made the problem worse. I'd like to be able to upgrade to Retrospect Mac 16 next spring so I can upgrade my Mac Pro "backup server" and MBP "client" to macOS 10.14 Mojave to get the benefits of APFS; maybe switching from Multicast to Subnet Broadcast—which I have just done—will enable me to do that. If Subnet Broadcast makes my intermittent -530 errors go away, that would be IMHO a sad day for Retrospect Inc. unless Retrospect 16.0 introduces an explicit fix for Multicast. If the fix isn't in Retrospect 16, Retrospect Inc. will have to distribute a very-prominent document (for Retrospect Windows, too, because some administrators have reported -530 errors with that variant) that says "Don't add your 'clients' with Multicast anymore, because it creates errors for some administrators. Instead use Subnet Broadcast; we know it's going to be tougher for you to learn how to do that but you're stuck with it." I don't think that will ease Tech Support's workload; quite the contrary, since they may have to process additional product returns from disgruntled customers.
  20. James Harris

    Verifying backups on B2

    I have a script that verifies my local backup sets monthly. I have an offsite set stored on B2. I know downloading costs but I also know that sinking feeling of finding out a backup is corrupted only after needing it. Simple question...Do I need to verify backup sets on B2 or am I just wasting time & money?
  21. Lennart_T

    Tape backup error 102 Win 10

    It could be practically anything. Have this EXACT setup worked before? If "yes", what happened before it stopped working? A windows update? A new SAS card? Anything else? I would start with (from the top): Check the firmware of the SAS card and the tape drive. Check the drivers for the SAS card and the tape drive. Try another cable.
  22. Mathemagier

    Tape backup error 102 Win 10

    Hi, I am having trouble when running a backup from internal HDD (Drivepool) to an LTO-6 tape with Windows 10 1803 and Retrospect 12: The backup exits randomly with error 102: Trouble communicating. I have an SAS-card LSI SAS9207-8i HBA (It-Mode) with a Tandberg LTO6-HH tape. Any suggestions for the root cause of this error? I already tried the following: Switched PCIe-Port on Mainboard Changed port of tape device at SAS-cable Kind regards, Andreas
  23. Lennart_T

    Catalog file is locked.

    What does Windows Explorer say about the files? Are they really locked? Do you have permissions to write to them?
  24. Just started happening. None of my scripts or manual backups will work. + Normal backup using The Guys Friday at 12/14/2018 10:04 AM (Execution unit 1) Can't add to Backup Set New Guys, the Catalog File is locked 12/14/2018 10:04:00 AM: Execution incomplete
  25. I was able to ping (e.g., see) from all clients to Multicast port 497, and from the server as previously describer. However I did not ping to Multicast from anywhere. Still assuming a bidirectional pathway. That’s the implication - Multicast to a machine is blocked? Robin at Retrospect mentioned a Multicast check tool - Multicast Ping for use on two machines to send and receive from each other. See this web page from the developer Mr. Dunagan. When I used the app supplied (Multicast Ping) current version, I was unable to ping from one client to the server when the app was running simultaneously, obviously the very one having the issue in Retrospect. I believe I was successful open up that port (create a firewall "pinhole") on the router IP connection to the client to see if that makes a difference, it should have been opened on the machine when I installed the Retro Client. Perhaps it will open up now, when I retest the two-way ping between the Server and this particular Client. The other devices (client and server) communicate with no pinhole configuration on the router, so I have no idea what could have caused this issue. Either way, it's simply a matter of interest. Since Subnet protocol seems perfectly fine.
  26. Your ideas have merit, I made "friends" with my router already, David. A long time ago. However, the router is not so friendly as to allow me to remove select inactive IP's singly. I have several IPs that, while inactive now, become active when the WiFi in the device turns on and the devices go from active on wired connections to active on WiFi. So there is NBO REASON to remove inactive IPs en masse. Irrespective to activity there is no reason that this is an issue the Multicast shouldn't take care of (multiple inactive users)itself and there are many reasons I do not want to willy-nilly get rid of all active or inactive IP's. No thanks. No, that's not what I said as to the IP assignment of my machines. They're not on the same IP. If you saw that, then it's an error. Let's move on. I've already proven (at least to my own satisfaction, if not yours) that based on the article Retro published (shared with you earlier) that Multicast works at the network level. So I disagree that it's a router issue in the first place. The ping proves that the IP's re being discovered. What happens within Retro beyond that is a Retrospect problem. I have static IP for my clients and have done so in the past. I feel very comfortable with my router (using it and diagnosing the performance of it) and the system I've got now. Although it's not the fastest in overall throughput, it gets the job done. I'm not making more trouble for myself than it's worth restructuring everything over and over, for no potential gain when there're multiple ways to discover clients in Retro. Emailed with a Retro support rep (Kyle) who's got a few more ideas. He suggests making the Subnet broadcast source selections work instead of the Multicast. Tried setting it up. This works very well and both clients respond to it without a problem. Obviously Direct selection of sources is a backup and also works fine, so I've got two paths to source machines, the latter being the most cumbersome. Fine. So Subnet selection's what I'll use instead of Multicast. There's still no good explanation about why Multicast fails, but I'm willing (more than, actually) to let Multicast go it's merry way without me. As I said, I've had too many problems over the years with it to believe it's happenstance or router issues as you indicate. Actually don't care to go further unless Retro support wants to carry on. I'm of the opinion that Retro's implementation of Multicast is the issue. Now, that I present the problem to Retrospect, simply not going to pursue it further.
  27. bradp015 got an answer by first making this post in the Server, SBS and Multi Server forum. His Retrospect Mac 9 success report, including methodology, is 2 posts below it.
  28. Lennart's method to move a storage set to a diff. hard drive works great! For anyone else doing this with Retro 9 on mac: When I chose a diff drive for the storage set the pathname listed did NOT change to the new drive path. On doing a test backup I returned to the storage set to look at the path and i DID change. So perhaps after you change the path to the new drive, cycle things by visiting another tab in retro and then return to the path page. If that doesnt work do a small test backup and then check the path. i would but it will be diff. and list the new destination drive path..... thanks! brad p
  1. Load more activity
×