Jump to content

Nigel Smith

  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Nigel Smith

  1. Nigel Smith

    Dissimilar Hardware Restore

    Thanks for that, David -- though to me it is still as clear as mud 😉 Luckily doesn't apply to us, with the way we use RS. DHR is definitely an "extra" -- RS's core task is to "restore what was previously on the client" while DHR adds "and then do whatever's required to make the new client bootable with its different hardware", so an automation of something you could do yourself. Talking to my PC-supporting colleague, he wouldn't bother with it unless we had frequent restores onto differing machines -- his example was a group of road warriors who have accumulated machines of different ages/models/makes over time and where a complete refresh onto standard Ghosted machines isn't worthwhile. I guess I've become the "boiling frog" -- I've spent so long looking at software that charges more because you're "Enterprise", looks cheap until you add per-TB usage costs, or seems good until you realise that *every* piece of functionality requires an extra-cost sub-licence, that now I just shrug and accept it. Thanks for giving me a shake-up! Now, if you could just turn the hot-plate off and lift me out of the saucepan...
  2. Nigel Smith

    Dissimilar Hardware Restore

    I'll leave my original reply in italics, below. But I'm losing my mind trying to work out what does what -- Retrospect's own pages seem to contradict each other: Single Server 5 includes "...Dissimilar Hardware Restore, making it possible to recover an entire boot volume—including the OS, applications, registry, and data—to a different physical computer..." while the DHR D2D add-on "...covers your Retrospect host server only." Implication: clients are covered by the base software, host server isn't. Single Server Unlimited includes "...Dissimilar Hardware Restore, making it possible to recover an entire boot volume—including the OS, applications, registry, and data—to a different physical computer" while the DHR Unlimited add-on "...extends to all Windows systems protected by your Retrospect host server, including end-user desktops and laptops." Implication: the host is covered by the base software, the clients aren't. Of course, they may have given very similar names to things which enable completely opposite use-cases... <Sigh> Probable garbage below... As I understand it (and I fully accept I could be wrong -- I *hate* trying to decipher licenses for any Windows software, since they all seem to be create to confuse!) those prices reflect different "abilities": DHR Desktop helps you to restore your *desktops* to different hardware -- applies to the Desktop for Windows product. DHR Disk-to-Disk helps you to restore your Retrospect host server to different hardware -- Single Server 5 already includes DHR Desktop functionality above Windows Server and Desktop, unlike the Mac and Linux OSs, really are different beasts -- and it's pretty standard across the industry to charge more for a WinServer-aimed product than WinDesktop. Whether that reflects a greater difficulty/cost in creating and maintaining the server product or is based on a willingness of businesses to pay more, I couldn't tell you. But if you think RS's pricing for this is bad, check out the competition. Better yet, have a look at Microsoft's Server OS licensing -- nightmare!
  3. Nigel Smith

    Dissimilar Hardware Restore

    IIRC, Desktop can have it without ASM, Server requires ASM. Slightly unfair. As a Mac user you've probably forgotten (or maybe never knew) the pain involved moving a Windows install between different hardware. It would only take one or two uses for a business to cover the cost of the add-on and, realistically, business is the target market. And not just for "restores", also for migration from old to new machines. I wouldn't bother with it as a home user, but if time was money...
  4. Nigel Smith

    Incorrect tapes names and possible overwriting tapes

    Not quite. It is showing three of the library slots are designated as cleaning tape slots -- it doesn't matter what tapes are in there, as you've seen, it just blocks out those slots during a device scan and tries to use their contents when a clean is triggered. Check that you haven't inadvertently marked off two more cleaning slots than you want... I don't think RS has "knowingly" wiped the second tape, since it is still listed as holding data on the set's Properties. "Unknowingly"? That would depend on whether it's dumb enough to only (mis-)read the barcode and not sanity-check the tape header before proceeding... Something's out of whack though. I think my first move would be to Disable Barcode Scans in Retrospect's tape library properties window then do a Scan Selected or even move the tapes in and out of the drive manually and see if that gives better results. Try opening/closing the library door *before* doing Scan Selected -- if it works like the Mac version it'll put all tape names into italics until they've been scanned, so you can easily see what has and hasn't been done.
  5. Given the above, it looks like a good test would be to compare the transfer of the veeAM files from the Windows client to a) an hard drive directly attached to the Retro server, and b) to tape. While everything looks good I'm starting to wonder if you've got a dodgy SAS cable or something. Would also be worth turning off the speed-enhancing features on the ATTO card, if you haven't already -- you hardly need them for this. As to cleaning -- you've done that far more often than I have! LTO is largely self-cleaning so, unless the library is in a dusty environment, you could get away with turning auto-cleaning off entirely and just doing it manually once a year or when you start seeing tape errors. But I'd still look at going D2D2T. Retrospect -- indeed, most backup solutions I've tried -- hate doing lots of small files to tape, especially when those files are on a mounted share. There's a lot of overhead for each file so you aren't using the tape drive optimally. You may even find D2D2T faster, if you can run multiple backup sets and your Mac Pro has the throughput to back up clients to Set A whilst also copying from Set B to tape...
  6. Which is another reason for asking about the drive make/model. LTO drives are clever and slow down the tape speed to try and match the data rate but even then there's a minimum speed and, at rates below that, underrun occurs. Although, at only 100GB on an LTO7, that sounds more like an interrupted transfer -- RS is interpreting it as a tape error, considers the tape done with (though the data is safe up to that point), and asks for another tape so it can carry on. I get similar with my not-really-supported Thunderbolt to Fibre Channel adapter...
  7. Nigel Smith

    unistall engine

    Open Retrospect Console, select "Preferences..." from the "Retrospect" menu, click the "Console" icon at the far-right, click "Export server installer and uninstaller...", save them where you want. Haven't actually *tried* the uninstaller myself, but see how you get on. Even if you've already manually uninstalled I suggest you give it a go in case it clears up cruft from your launchd files, logs, etc.
  8. Sounds like you've got problems with the library/drive. What make/model is it? I try to use Retrospect Client on the source servers rather than SMB-mounting them onto the Retrospect server since I find it generally works better -- an interrupted/resumed SMB session is usually handled fine during, say, a Finder copy but can be death to a backup. Otherwise, try the usual troubleshooting: how fast is a Retrospect Server to tape backup (i.e. eliminating SMB from the problem); how fast is a backup of SMB-mounted share to a disk directly attached to the Retro Server (i.e. eliminating the tape drive), and so on. For best speed you may want to look at a disk-to-disk-to-tape setup... As to overwriting tapes -- we don't do that here but, IIRC, that's what the "Recycle Media Set" media action (in the "Schedule" pane of the script definition) is for. Or have you tried that and found it doesn't work?
  9. It would be a new volume. You can try it for yourself with a USB stick -- add it, tag it and add as a "Selected Volume" in RS, rename it, refresh, and the tag and selected status is gone. As Lennart says, by default the files won't be backed up a second time. Unless you've selected "Match only files in same location/path" in the script options (which is off by default, I believe).
  10. Nigel Smith

    How to restore files on top of what's there?

    Thinking about this, your recovery might be easier than I thought... Make a new backup, to include everything created/modified since the last of the old backups Restore Volume using the old backups Replace Corresponding using the new backup Assuming the matrix is correct, that should mean that "corrupted" files are returned to their uncorrupted form then new/changed files are overlayed, replacing previous versions where appropriate (assuming you weren't doing something silly like editing file data without updating the metadata to suit). All you should lose is data created/modified *after* the last old backup but *before* the borkage *if* it was affected by said event -- that would require data recovery of some sort.
  11. Nigel Smith

    How to restore files on top of what's there?

    The documentation could be clearer -- "Retrospect leaves files untouched if their metadata is identical...". That's good enough for the vast majority of use-cases. What you want would require checksum comparisons and a whole lot of extra processing. Could they offer that as an option? Maybe. But "Replace corresponding", even if it worked as hoped, wouldn't work for you anyway since you said there are changed files which you *don't* want replacing -- in fact, you want "files whose metadata matches but checksums don't". In this particular case I'd guess your best bet is to full-restore to another disk then walk the original's tree, copying across files that match your criteria -- a nice little scripting project 🙂 Since you appear to have a time-point, you might also be able to build a copy with a backup restore followed by a time-filtered Duplicate from original disk to the copy. You could then replace the original with the copy. No easier than your proposed workrounds, but you could let Retrospect get on with it while you enjoyed your weekend...
  12. The S.M.A.R.T. tab itself might give more information -- what's there depends on the software, but there should be a note of the number of unallocated blocks, how many have been mapped out, etc. See the wiki page for the amount of info potentially available. Your disk is in perfect health -- what we can't see from that screenie is if it is in perfect health because nothing has ever gone wrong, or is it in perfect health *now* because previously found "problematic or weak sectors" have been mapped out. Also, that's a very new disk. Only 13 days of being used, primarily (if not wholly) a backup disk, and you felt the need to defrag? That seems odd in itself. Not that any of this really matters to the original problem, I just like to scratch an itch when I find it...
  13. Could you go back to whatever version you were using before you "upgraded" to 16.1?
  14. Surface test only checks "usable" disk space -- it doesn't include bad sectors that have already been mapped out. So it's probable that the "missing" files were on a bad sector that has already been "fixed" by Windows. Possibly, given the numbers involved, a problem in whatever is NTFS's equivalent of the file allocation table. You can check by viewing the SMART data for the drive, which will tell you how many sectors have already been re-allocated.
  15. You might still be carrying some cruft over from the "old" directory structure. Instead of what you did, copy (not move) the members from old to new directory, creating any required sub-directories by hand as you go. Set all permissions to the same as the newly-created top level Retrospect directory. Get Retrospect to "Rebuild" the media set, adding members as required, but make sure to save the new catalog in a different location so you don't overwrite the old one. That's quite a lot of work. But it could get you out of a hole if you need to keep the old sets available for restores -- you never said in the OP if Retrospect still had the read-access that restores require. If it does then I wouldn't bother, just move onto the new sets.
  16. Doesn't need much. NASs usually use Windows ACLs for permission control, which don't directly translate to POSIX/OS X permissions. So it's always a "best approximation", can be tighter or looser than expected/intended, and can be interpreted in different ways by different programs (if they aren't using OS X's APIs). I'm not expecting my workround to work, but it's worth trying before you contact Support -- more data points will help them help you.
  17. Nigel Smith

    AWS virtual tape library

    But S3 would also offer you Standard, Glacier and even Deep Archive. So you could use Retrospect's Cloud Backup or Disk Set(s). I've never used Cloud (some who has might want to chip in) so I'd probably default to Disk Sets with reasonably small member sizes, generated on-prem then uploaded to S3 Standard once each is "full", then migrating from Standard to Glacier after a year or so. There are many ways to skin this cat -- how exactly you do it will be prompted by your data, how you manage your backups, how the regulations say you *must* manage them, how much money you're allocated for the job, etc... The use-case for VTL I thought of first was "lots of physical tapes which I can put into cloud storage by duplicating through the Gateway" i.e. you need to generate an exact virtual replica of your current physical holdings. If that isn't a regulatory requirement and you can manage the migration using Transfer operations from tape set to Cloud/disk set, VTL support may not be needed at all.
  18. Nigel Smith

    AWS virtual tape library

    Why use a VTL instead of doing a "normal" disk backup set to an S3 bucket or similar cloud service? (I can think of some reasons, but would be interested to hear yours.) Regardless, Retrospect isn't listed in Amazon's supported applications table and neither media changer is listed by Retrospect (unless the STK-L700 is close enough to e.g. the SL500 that it'll work), so I think you're still left waiting. Or very much on your own if you try to make something work. As David suggested, try contacting Sales. You may get lucky, and at least you'll flag it as something for them to consider in the future.
  19. What happens if you let Retrospect make a new set in a new, separate, directory on the NAS -- i.e., instead of your current NAS/folder1/folder2/Retrospect structure you do NAS/folder1/folder3? Can it create and, afterwards, verify the test set OK? If so, check for any permissions differences between the two using the NAS's management interface. Sometimes a NAS, which is usually running a SAMBA variant, can present itself in different ways to different OS X programs. And if the first step works but you can't see any differences, try copying one of your "old" catalogs into the "new" Retrospect directory. Can you access that now? In which case you might be able to get round the problem by moving all your catalogs to the new folder.
  20. What Lennart said... Plus, if you are running Windows with concurrent users, you can get similar symptoms with only one copy of RS installed. Next time it happens -- and I'm sure it will -- try the "resmon" thing above and see if that points to the culprit.
  21. ObDisclaimer -- I know little more about Windows than what Mr Google tells me. With that out of the way... It would be worth checking if any process has that catalog file open (which would make it read-only to RS, hence the "locked" error). Click "Search Windows" in the Taskbar, type in "resmon", then hit <Return> to launch Resource Monitor. In the "Associated Handles" section type ".rbc" in the search box and hit <Return>. Mouse over each path in the "Handle Name" column and see if any refer to your catalog file. (When I do this I get two lines back, one for "explorer.exe" referring to a registry key, the other for "Retrospect.exe" pointing to the currently running backup's catalog). You could try increasing the other logging settings (yes, "7" is the max) -- I have *no* idea what you'd be looking for but, if it was me, I'd create a new set, flush the log, do a manual backup of a single folder to that set, save that log and flush, then do a manual backup of that same folder to the borked set, save that log, then compare the two logs to see what was different. If nothing shows there then I'd be thinking along the lines of: David's suggestion of trying the trial version of v16 and seeing if that solved it Restore previous version of catalog then repairing it to bring it up to date Retiring the old set (keep it in case you need to restore from it at some time) and starting a new one If desperate to keep a single running set, archiving the old catalog (just in case...) and starting a "new" set by recataloging your current backup data
  22. Have you got the new drive fitted yet? If so (i.e. hardware fault is now out of the equation), I'm thinking you've hit an internal limit on catalog size/contents or member size. How big is the "locked" catalog file (in Windows Explorer). In Retrospect's properties for that Backup Set, what's the "Used" space and file count? Then copy that locked file of to your C drive, back to G, and "relink" it as you did before to unlock it. Check the above again -- what are the numbers this time? If the unlocking trick works, try adding another member and continuing the backups. If everything continues working it was a "member size" limit (Ooo-errr!), probably from a weird coming together of RS, Windows 10, and Synology's volume presentation. If, however, the catalog "locks" again very quickly you may have hit a file-count limit -- you might be able to groom the old catalog and then carry on, but maybe it's time to start a new set. Otherwise, it's log time! Towards the bottom of the page from David's link above you'll find instructions on how to access "Secret Preferences" and change the log levels. You can generate a lot of noise with these, so I'd start by leaving everything as is except for winding up "Backup Sets and Catalog Files" to the max. Try another backup and let us know what the Operations Log reports.
  23. Nigel Smith

    Catalog Rebuild issues V16 OSX

    Nice catch! Had forgotten that -- our main v6 backups are Internet Backup Sets, which can't be rebuilt in any recent version. At least you won't have to do the multi-terabyte restores I'm (slowly!) going through 😉 I know v10.5 will run on OS X 10.6.8 through 10.9, not sure if it'll cope with Yosemite or higher though. Anyone?
  24. Nigel Smith

    can't connect to server

    Then I'm very surprised that you have something listening on port 22024 on the Console-running Mac. You might want to find out what that is, if only for your own peace of mind. Check System Preferences first -- the clean Mac I did the test install on (above) *did* have Retrospect Engine running at the the end of the install process, even though I never asked for it or entered any license info etc, and was listening on 22024 until I turned it off (and unchecked "Launch on System Startup" to be sure it stayed off). Otherwise, in Terminal on the Console-running Mac, enter "sudo lsof -iTCP -sTCP:LISTEN -n -P | grep 22024". The first word of the returned line is the reported name of the process, the first number is its Process ID (PID) -- you can use either in Activity Monitor to work out what is going on. Again, if it is RS Engine I don't believe it would cause your problem -- but why spend the resources if you don't need it?
  25. Very true -- I think this will catch out most people the first time they try it so thanks for the reminder. The latest manual does include that information, albeit in the "Disaster Recovery" section. IMHO there should be a big banner announcing that fact in the "Restore" section as well, or at least the "If you have experienced disastrous data loss..." paragraph amended to "If you want to restore your System drive or have experienced disastrous data loss...".