Jump to content

Nigel Smith

Members
  • Posts

    348
  • Joined

  • Last visited

  • Days Won

    25

Everything posted by Nigel Smith

  1. IIRC, you have have to go from vWhatever -> v6 -> v10. In v10, try using Backup Assistant and selecting "Search for files in selected media sets" in step 1. Then, in the "Search Files and Folders" dialog, use "Any" and "File Name contains" but leave the text box empty (see pp 142-145 of the v10 User Guide). Do check carefully -- run Restore Assistant on the rebuilt set and see if the "More Backups..." button gives access to the "missing" snapshots. But I honestly don't know. My experience is with v6 Internet Backup sets, which can't be converted, so I've been doing full v6 restores (including every versioned file) of every client and then backing up those restore folders with the newer RS version. I'd hope it would work, but if your experience says otherwise you should trust it! But do you need to do point-in-time restores from those old sets? I have no need of recreating an hard drive from 10 years ago but I do need to be able to eg pull back original experimental data if it is ever questioned -- your actual needs may also make snapshot retrieval unnecessary.
  2. Sorry -- my stupidity. Of course the "Locate" command is used to point to the catalog file. D'oh! Can you post the paths of the two Backblaze Storage Group directories for the same backup client? Might be a clue there...
  3. Do a search with both the "Include" and "Exclude" boxes empty -- that should return every file that was ever backed up. You should be able to re-catalog the tapes in 10.5, then directly "Copy Media Set" from tape to a new disk media set, retaining all snapshot information etc.
  4. When you used "Locate", what did you select? I haven't used a cloud target, but I suspect it is the same as a mounted-NAS target and you should be selecting the volume/directory that contains the "Retrospect" directory that holds your backups, not the "Retrospect" directory itself. (I often get that wrong, usually with the results you describe!)
  5. It's probably comms with the tape drive that are causing the problem, but make sure by disabling the iSCSI initiator, turning off the drive, turning off the RS Engine auto-start, rebooting the Mac, waiting 5 minutes (for log messaging to settle), manually starting the RS Engine and then launching console. (Manually starting the Engine gives you a known time-point for you to check the system logs.) If all is good, do the same but this time with the iSCSI initiator enabled. Then the same but with the tape drive turned on. I'm betting it'll reproduce the problem in the last test. As David suggests, you should try again with the drive on but the iSCSI initiator disabled, just to be sure there's no clash there. Then we're on to details -- SAS card, tape drive type, make sure card and drive firmware are correct for your OS and Retrospect, re-seat the SAS card, try a different cable, etc.
  6. How did you try to restore the "entire backup"? It sounds like you are restoring to a "point in time", which (usually) won't retrieve every file that was backed up because it won't include previous versions of a changed file. If you really want everything that was backed up (rather than everything that was on the source disk for the last back up) use the "Search for files..." option, leaving the search fields blanks. That way you'll also get eg "datafile.txt" for the original file plus "datafile.txt-1", "datafile.txt-2" and so on for the more recent versions. Also -- to recover from v6 sets you need to have RSv10 or higher. So you could use the current version, either properly purchased or via the trial license.
  7. I wish... Unfortunately, I'm also having trouble finding two available machines that'll run both Catalina and Big Sur -- all but one are too old for the latter. So any testing by me will have to wait. Sorry about that.
  8. Except, from the descriptions, it's a bug in 17.5.1 on Big Sur but not in 17.5.1 on Catalina. And Big Sur itself seems to be rather variable, with eg reports of general big slowdowns on recent Fusion-drive iMacs while being really nippy on old SSD MacBook Airs. I'd promised a test on my Big Sur Mini -- the wrinkle is that that's an M1 machine, throwing yet another confounding factor into the mix. So I'll try and find something else to test on, which'll let me speed trial the same setup on both Cat and Sur. The problem will be finding a spare bit of kit that isn't so old that backups are dog-slow in both tests!
  9. I'll admit, I get very confused about what to select during various Media Set operations... It's usually "the directory that contains the 'retrospect' directory that contains your media sets", sometimes "the 'retrospect' directory that contains your media sets", and occasionally the media set itself. So I just work through them, in that order, until it works -- and then forget for the next time!
  10. OK, so it sounds like Server and clients all on 10.15.7 -- fast backups Server and clients all upgraded to 11.0.1 -- slow backups So it could be clients, or server, or both. Try a test backup of a folder on the iMac Pro to the RAID, to take network ops out of the equation. Try a straight Finder copy from the iMac to the RAID, to take Retrospect out of the equation. And as David asks -- is this a hardware or software RAID? The good news is that you've now got full backups of everything and can now use incrementals, which will take a lot less time even with those slower speeds. So you'll be OK, even if it takes a while to find a fix.
  11. Given that AVM themselves say you'll not get things to work and that unit is EOL and so not getting firmware/OS updates, I'd give this up as a bad job. Not all Samba implementations are equal, and it seems that AVM used one that you can't force to work with Catalina. Assuming you don't want to get a new router or replace your USB drive with a "proper", standalone, NAS, I'd go for a fileserver with the drive connected. Got an old Mac or PC sitting around? Use that. Otherwise, nice little project for you -- a Raspberry Pi running Pi OS or Ubuntu Server, which'll not only be more secure but probably faster too! A Pi 4 Model B, case and PSU would only cost ~£50
  12. To clarify: Catalina server with Big Sur clients = 2GB/min Big Sur server with Big Sur clients = 500MB/min Correct? What are you backing up to (local disk, tape, NAS, etc)? Have you a similar slowdown with eg Finder network copying using the server? What kind of speeds are you getting with an RS "Copy" rather "Backup" operation? It'll help Support if we can nail down where the slowdown is happening -- network transfer, writing to disk, or somewhere else. I might have a Mac Mini turning up later this week that I could, perhaps, "borrow" and try and replicate the problem.
  13. So it's connecting, but not authenticating... Did you also set minauth=none in /etc/nsmb.conf?
  14. NetBIOS is disabled in Catalina, which is probably what's breaking things. See here for how to re-enable. You may also have to use "cifs://serverAddress" rather than "smb://serverAddress" to force an old-style connection. Or upgrade the NAS, of course 😉
  15. Perhaps you and David could form a club? If there's T-shirts, I'll join!
  16. Not being a Windows user, I wouldn't no if there was useful information missing or not! I'll take your word that it isn't. What I can't see from your screenshot is which is your "Active" partition. Googling that app log entry mainly gives (old) mentions that OEM tools will make the OEM partition "Active" whereas System Backup (based, IIRC, around VSS) needs the System Partition to be active, plus a few more that may or may not be malware related. As well as David's questions, I'd ask: Has this ever worked? If it had but has stopped, what changed?
  17. As I understand it (and, like David, I'm a Mac guy), shadow copies aren't necessarily stored on the volume they are copies of. I thought the default was C:, but maybe that's old info. Veeam has a decent article on troubleshooting this, and you should be able to get more information by looking for VSS errors in the application event log. I also notice you are using BitLocker -- I believe that means you must store shadow copies on their originating volume. My Win 10 test machine does have a "System Reserved" volume -- and way fewer volumes than yours! Could you drag the divider down to show all volumes and repost the screenshot?
  18. It was a suggestion aimed at "home users" having this problem, rather than yourself -- you (we!) need a better solution. The "cool application" for us Mac users is Migration Assistant. Old Mac, new Mac, ethernet cable between the two, fire up Migration Assistant on both, answer a few simple questions and walk away -- and when it's done, there's all your old "stuff" on your new machine, good to go.
  19. According to an old post by Lennart, the closing phase of a Duplicate/Copy script involves setting permissions on all the target files, not just the ones copied over in that run. If still true that could explain what you're seeing -- and be another push towards doing "proper" backups rather than using Copy. But "Closing..." includes a bunch of other stuff too, including catalog updating, and doesn't let you know which "sub-task" is taking the time. You might learn more by turning up the log levels (long, and high variable, "Closing..." times have been a regular feature on the Forum over the years, and I don't think they've ever been satisfactorily explained/resolved). If I ever get my codes for RS17 (grindingly slow procurement process here) I'll try a similar test to David's.
  20. Nah, it was this one. Mis-remembered and not really relevant, I guess.
  21. Sure -- what I'm trying to understand is why you've chosen Copy rather than Backup, where you'd do the first backup in the office then the much smaller incrementals over slow connection. It's faster to record the file metadata in the catalog than it is to recreate it on the server (if that, indeed, is what the bottleneck is). There are reasons to choose Copy -- you want to replicate the user's data on your office server so others can use it, for example. 30% churn still seems awfully high, though (unless your situation is of people not having many files, but changing those they have frequently?). I'd take a good look at what is actually being backed up and check the filters are working as expected. I'd avoid Recycle at the moment. That would mean starting all over again every so often, so all the data would have to be transferred again over the slow, remote, connection. The thing with Grooming is that it saves space on your target disk by throwing away the "unwanted" data (eg previous versions of a file) but keeps what's current, so the next backup is just another incremental, with the much smaller transfer that implies. "Resetting" with a Recycle is great for David, with his high-speed LAN, but will probably hurt you more than it helps. Start with defining what you are trying to achieve. (Backing up user data? Replicating it? Just "Users" or the whole volume? Etc, etc...). You can get similar effects with different methods, but there's usually one way that's more suitable than the others.
  22. It was something about backing up (or to!) a NAS volume and seemed weird at first but obvious in (hah!) retrospect. Using Windows settings because it was an SMB mount? Using Mac settings because, although it was a Windows server, it was mounted on a Mac? Whatever it was, red's posted status message is pretty Windows specific and while I don't hold out much hope changing that client setting will help, it won't hurt either -- so even a tiny chance of success makes it worth a try.
  23. So are you doing a Copy that replaces everything with what's "currently" on the MacBook (and other clients), or just replacing the ~30% of files that have changed and leaving the unchanged files in place? Is it 30% of files, or 30% of data? Are you applying any filters? Are you, perhaps, backing up huge numbers of small cache files that you don't really need to copy, or some big files which actually only change in small ways (databases, VM images) that could be handled better? Could you just add a couple of external USB drives to the server and increase your capacity? If you could get the stage where you can store all the weekday incrementals, groom the set down over the weekend, then start again with incrementals the next Monday, that would probably make your life easier. Lots of very small operations, like one-by-one file metadata updates, can be ridiculously slow over a remote link. The more you can minimise them the happier you'll be.
  24. Give that Windows client setting a go anyway -- IIRC, Lennart found some unexpected "leakage" between client settings a while back. Or it may just be mis-reporting its activity and is actually setting ACLs etc on the copied files. Possibly a dumb question -- but why a copy operation rather than a backup? That would probably be a lot faster, especially since it wouldn't have to reset metadata on each of the thousands of small files in your Library folder (which, I suspect, is the problem).
  25. Weird -- that's an option in the Windows client section. You could try turning it off there and seeing if it makes any difference. Version of RS server, version of client, and OS version of both would be a help here. Also info about the destination -- you're not trying to "copy" to a Windows share, are you?
×
×
  • Create New...