Jump to content

MrPete

Members
  • Content count

    86
  • Joined

  • Last visited

  • Days Won

    5

MrPete last won the day on July 27 2018

MrPete had the most liked content!

Community Reputation

6 Neutral

About MrPete

  • Rank
    frequent Poster

Recent Profile Visitors

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

  1. MrPete

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

    Remember, it's not that the SSD fails. It's simply not an archival storage medium. Not so sure we can say HDD's are *that* much better today. My work on early drives (yes I've been doing HDD's since the 1970's around that long) ) was simpler, because the stored bits were monstrously big compared to today. (Anyone here remember the technique of literally using a pencil eraser tip to shove an HDD into spinning? They were truly not sealed!!! Meanwhile, today we no longer store bits in the HDD magnetic wiggles. We don't even store encoded bits. Today, it's more like a Douglas Adams sci fi joke! Adams talked about the "improbability drive"... well, how about a "probability curve"?! To compress the data, we calculate an exponential function that represents the bits in a sector, and store the parameters of the function. If one bit is wrong, you just lost an entire sector. That's "PRML" (Partial Response, Maximum Likelihood") ... such fun 😄
  2. MrPete

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

    Sigh. Mark, thanks for confirming what I sensed. This really is a bug in Retrospect. I'm about to report it. Let's say you choose "Replace Corresponding Files" from the dropdown. My expectation: it will replace the corresponding files. The documentation is clear about this. Unfortunately, it doesn't work. Retrospect ASSUMES that the data content matches, if the metadata matches. Boo. I guarantee that the "already copied" files aren't the only ones... and in fact, if I prepare a *backup* of the bad data, it's going to copy way more than a few hundred files. Time to report this bug. ======== A few quick comments on Mark's other suggestions: Preserving Data: In my situation, I've already replicated the drive. Nothing will be lost. SpinRite: I know exactly how/why the drive was partially zero'd. (It was my mistake )... no need for SpinRite this time. (YES I highly recommend SpinRite... Look for Pete H here - https://web.archive.org/web/20040825043909/https://www.grc.com/sr/testimonials.htm Bit Rot and Drive Replacement: In reality, bit rot can happen on ANY drive. In no way does bit rot imply a drive that needs to be replaced! Just for example: Consumer SSD drives retain data "perfectly" for approximately one year (if you've not overwritten a sector) before bit rot begins to show. It's worse for enterprise SSD's (because they are focused on performance over data retention.) This is not exactly advertised by the industry. Dig into the latest research and you'll discover the reality..) NOTE: some mfg's MAY be compensating for this and taking care of it in firmware... but I have yet to see such workarounds documented. And YES I have been harmed by this. Consider: what is the one sector on a drive or partition that NEVER is overwritten?... (How to avoid this: regularly rewrite every sector of an SSD. I do it about 3-4 times a year. I could point you at the (very!) technical research work that underlies what I wrote above. I agree that it's more than a little surprising.
  3. You might find this post from last year helpful...
  4. I am surprised this is not an obvious functionality. Scenario: - Existing drive, good backups - For !@#$% reasons, a chunk of an NTFS partition was literally zero'd out at a low level - Result: files are all in place but I guarantee their contents have changed. Consider it bit rot on a massive scale What I need: - Restore essentially all backed-up files, ignoring the fact that the metadata matches perfectly - In other words, I want to do a restore-with-overwrite. - Important note: I do NOT want to simply restore the volume if at all possible, because there are many new/changed files not in the backup. I can't find a way to do this. What am I doing wrong? Mostly, it auto-deselects all the files that appear to already be there (matching in size and date stamps). Any ideas much appreciated. I'm about ready to do the obvious/pain-in-the-neck workaround... - Find all new files and copy elsewhere and/or - Delete all files that aren't new THANKS! Pete
  5. Very interesting... * The AA*.rdb files are from mid- May 2018 and today * The AB*.rdb files are from June 2018 all the way through until today * Somehow they were both in the same folder and Retrospect was not upset... but it sure was upset now! AA rebuild finished AB rebuild under way...
  6. I solved it, and learned a few things along the way. I finally examined to see what was so special about 262 files... and discovered something I probably should have noticed before: the folder contains TWO sets of *.RDB files! AA*.rdb and AB*.rdb -- AA*.rdb is 262 files. I am guessing it is what had been built during the failing groom, **even though** most of the files have a create and modify date that's quite old! So: * I split out the AA*.rdb files into a separate folder and am rebuilding a catalog on those just to see what's there * Then i'll rebuild the AB*.rdb files
  7. I wonder if anybody has an idea I can try. I'm stumped and support's closed for the day. I have a backup set with : * (1.4GB) catalog file. * 1.7GB of backups in 2.3 million files, 527 sessions, 132 snapshots. * The backup set has around 5000 *.RDB files. I went to groom and the groom failed. Now I need to rebuild the catalog. PROBLEM: no matter what I do, the catalog rebuild only scans the first 262 RDB files?!!! I have: * Rebooted * Deleted the old catalog file * Checked all permissions Any ideas MOST welcome! pete
  8. MrPete

    Retrospect 15.6 status?

    According to the Blog, 15.6 was announced on Tuesday. https://www.retrospect.com/en/blog/2018/10/16/retrospect_15_6 It's available for download now. https://www.retrospect.com/en/support/downloads However: My 15.5 Desktop/Pro does not see an update available Mayoff hasn't announced it here QUESTION: Is the new version safe to download and use?
  9. What I see here is: - Someone is attempting to use WikiPedia as a wiki platform for writing Retrospect user-generated info of various kinds I would suggest backing off from that. As others have noted, Wikipedia isn't a particularly trusted platform anyway, and they dislike misuse/abuse of the platform. Alternatives include: - Perhaps Retrospect could implement wiki.retrospect.com - Or, just make a shared Google Drive folder. Easy peasy.
  10. (At long last, I have filed a support case with extensive info on how/why I recommend this change...) Here's what I wrote: Hi! In 2014 KB article https://www.retrospect.com/en/support/kb/file_vs_block_deduplication your team discusses why you've chosen File-based dedupe, based on name/size/attributes. I strongly recommend revisiting this decision, due to changes in technology, typical usage, and data volume. AND, there's at least one good implementation in a competitor that demonstrates the advantages of a move to block-based dedupe. Tech change: hash calcs are *extremely* fast in modern CPU's. Both traditional and new ones (cf CityHash). Multiple GB/sec! Storage technology now easily exceeds 100MB/sec, often to 500MB/sec. Data volume: with multi-TB drives, large SSD's, 4k video and large photo sensors, it's quite common to toss around many many GB of *noncompressible* files. Many TB in fact. Compression has little value as we move toward photo/video media. Typical usage: File-metadata dedupe is woefully inadequate today. The 2014 article doesn't cover many common scenarios: the exact same 20MB photo is often renamed as it gets copied to dropbox, shared with others, etc. Multi-MB audio files can have header info significantly changed, while the modify timestamp is retained. (eg every play causes the play count to update in the file! Yes, the access timestamp is updated. Photo and video collections are typically duplicated, renamed, and minor metadata header info is updated, while the bulk of the data blocks are not touched at all. A simple partition copy can cause Retrospect to make a new backup of every file in the partition. Many modern apps use the same DLL. Unfortunately, filenames and timestamps *often* vary (for identical content.) (A great, paid, tool I use for content-dupe-finding is SpaceMan99. Run it against a ? drive on a well-used computer!) C:\Windows\Installer contains duplicates of installed executables, with different names. Many hundred MB. Right now, all of the above scenarios cause anything from waste to havoc in Retrospect. One commercial example that handles all of this quite well: CrashPlan. (They left the home and SMB market last year, so not really competing anymore...) The client maintains a local database of file metadata and block hashes. Across the board, a "file" is a [metadata packet] plus N [content blocks]. Metadata can be quickly scanned for grooming, storage, recovery purposes Content block references can be efficiently rebuilt as needed via a scan Deterioration of both source and backed-up blocks is easily detected via a scan, and re-backup solves it - Up to N copies of any given content block can be retained for redundancy.
  11. I've updated the Admin Guide with new information. - More details on recovery in tough situations - clarified GPT/MBR partitions vs BIOS/UEFI boot support - clarified my latest understanding of what boot info is saved, backed up, known to Retrospect and the DRD. LATEST: 1) It now appears that the DRD is intended to function correctly with both BIOS and UEFI boot environments. Not sure if it does. 2) Retrospect is supposed to back up the System Reserved partition (but not the System Recovery)... however... a) There's VERY little indication that this happens (I see some info in some log files) b) I don't think it actually works for BIOS boot environments Yes, this has all been reported and I'm in discussion with support. (I'm providing this info in a very timely manner because I know for myself how frustrating it is when you lack information in a disaster recovery situation!) OK, back to my normal work.
  12. AFAIK you don't necessarily need separate client vs server DRD's. I'm working to get clarification on some of these things from the tech support team. They are definitely aware of the confusing documentation etc.
  13. Please read my Admin Guide - it explains the kinds of things that cause you to need multiple DRD's (AFAIK). Assuming these are all client machines, the varying hardware is not the issue. The real issue is that at least for now you may have different partition layouts you need to know... different disk partition tables (MBR vs GPT), and possibly different boot methods (UEFI vs BIOS.) Restore to dissimilar hardware refers to restoring a single computer: if the original computer dies and you don't have an exact match replacement, you need to restore that computer to "dissimilar hardware." ?
  14. Are you restoring a client or the (Retrospect) host? If a client, why not just try it? You have nothing to lose but some time. You're starting from scratch anyway
  15. Thanks, David. We'll see how it goes...
×