Jump to content

rhwalker

Members
  • Content count

    5,089
  • Joined

  • Last visited

Everything posted by rhwalker

  1. rhwalker

    Restoring files and folders

    The answer is complex, and, basically, is "it depends". A System Recovery pulls back a system checkpoint that was made at a given instant. There may have been System Updates (or software updates for some applications) that changed applications from that point forward. Applications from the present may be incompatible with a System Recovery from the dark past. Some applications, particularly on Windows variants (as contrasted with Unix variants) reach into System Files (e.g., the Registry) and install keys to enable them to work. A System Recovery, depending on the date of the checkpointed system, might not have all keys needed, and it might be necessary to do an application install process to bring the system to a runnable state for those applications. And the converse can be true - if you blindly install a current Registry set into an old system recovery, that might confuse things as well. I really wish that there was a simple answer. Remember, you seem to be dealing with an unknown problem cause ("system runs slowly"). Basically, there seem to be two approaches: (1) Go back to the complete system you had when things were "working right", including applications in place at that time, then bring it forward (carefully) by updates to the system and to the applications. One way to do this approach is to periodically clone your drive(s), save the cloned drive(s) away. A quick way to do this is to create a RAID 1 mirror, let it rebuild in the background, shut down services, split the mirror - instant copy. (2) Let Retrospect take you back to a certain place in time. The problem with this is that you have to make sure that Retrospect backed up all of the necessary files (see the Recovery Disk method provided by Retrospect), and Retrospect (or any program) can have problems backing up open files. Also, certain database programs (e.g., mail servers, etc.) need to have a consistent database from which to restore, and the database can't be changing while individual files in the database are being backed up. For such cases, you have to stop the service, checkpoint (or clone) the database, restart the service, and have Retrospect back up the checkpointed database rather than the live database. Backup of User data is much simpler. Backup of live systems, though, is complicated. I wish that there was a simple answer. In the case of a server (or even a user system), many people use a two-pronged approach. Make a working clone of the boot volume (see RAID 1 mirror split above) before any software update, save that away so that you can bring the system back up in case of disaster. Then segregate all user files on a different volume (or volumes), back that up using incremental approaches (e.g., Retrospect) so that you have the version history desired for such files. It all depends on your backup policy. You do have a backup policy against which you evaluate your backup strategy, don't you? If not, I suggest you see this web page, which raises some of the issues that need to be addressed: What Should a Good Backup Policy Address? Here's another link to the same page if that link doesn't work - some browsers have problems: http://iwiring.net/#[[What%20Should%20a%20Good%20Backup%20Policy%20Address%3F]] Russ
  2. rhwalker

    Testing 8.2 without uninstalling 6.1

    Yes, providing that you have your 6.1 schedules disabled so that there won't be an unexpected 6.1 launch for a scheduled backup. See: RetroRun mystery explained Russ
  3. rhwalker

    Media versus thorough verification

    You draw incorrect conclusions. MD5 verification is two operations in parallel (assuming reasonable buffering, reasonable thread factoring, and neglecting the negligible anomalies on start and finish) - read the source, and compute MD5 checksum. The gating item may be the speed of the I/O channel and the backup device, or it may be the MD5 calculation (depending on how well Retrospect's calculation is implemented, and also depending on the CPU horsepower of the machine on which the Retrospect engine is running). Comparison verification is three operations in parallel (assuming reasonable buffering, reasonable thread factoring, and assuming that the source and backup devices are different and don't compete for the same I/O resources) - read the source, read the backup, do the comparison. The comparison (assuming even a poor implementation) is certainly not compute bound. The two reads may be completely overlapping, with complete parallism, if they are on different devices. If the backup device is the slower device, then the comparison verification may be as fast, or potentially even faster (if the MD5 verification is compute bound), than MD5 verification. It's not a simple question to answer. You should test on your setup, with your particular choices of hardware and technology for the backup device and the source device. The choice between the two approaches should not be made based on assumed speed. Again, the two approaches serve different purposes. Russ
  4. rhwalker

    Restoring files and folders

    I believe that you are confusing "backup" (which necessarily means preserving versions of each file) with "sync" (keeping the latest updates of files in a folder). The two terms aren't synonymous. Step back a bit and re-read what I wrote, and compare with your post. You may be wanting "sync" rather than backup. If so, then Retrospect is not the best tool for that job. If you want "backup", then understand what that means, and it will make your use of Retrospect much more pleasant. Russ
  5. rhwalker

    Rules - Explicit Path

    One way would be to define /Users as a "Favorite" (formerly known as "subvolumes", implemented as chroot). Doing it that way avoids scanning the entire boot volume. Remember, by the current Retrospect design, first the entire volume's filesystem is recursively scanned, building a file list, then that list is passed through the selector filters (um, Rules), to create the list of files eligible for backup, and then that list is compared against the contents of the backup set (um, media set) to see what files have changed. If all you are going to back up off of the boot volume is that one filesystem branch, you might as well limit the scanning to that branch. Russ
  6. rhwalker

    Disk vs File media options

    Retrospect 8 "disk" media sets are a completely different animal than Retrospect 6 "disk" backup sets. It's truly sad that the same name was used for both. While pointless confusion can often be caused if an old feature's name is changed for the same functionality in a new release (e.g., Retrospect 8's "rules" vs. "selectors", "media sets" vs. "backup sets" (and that term has changed several times over the life of the product), The most confusion is always caused when the same name is used for different functionality. That's what has happened with "disk" media sets (vs. "disk" backup sets and "removable disk" backup sets). Probably the best synopsis I have seen is on page 6 of the "Retrospect 8 Getting Started Guide": You just have to do a "brain reset" and understand what Retrospect 8 disk media sets do. Part of the problem is that everyone tries to understand the underlying implementation rather than just comprehending the abstraction (now possible) that it's now just a bucket of bits into which you dump data. With all of their new advantages, it's very hard for me to see any reason at all to use anything other than "disk media sets" for all backups (previously file, disk, removable disk, or optical) that aren't to tape, and it's probably worthwhile, since you have to rebuild old 6.1 catalogs anyway, to transfer those backup sets to 8.x disk media sets so that they could be groomed, could span multiple volumes, etc. Retrospect 8's disk media sets are a significant design improvement. Now, none of us users have seen how "internet" backups (f/k/a/ FTP backup sets) will be implemented; we've seen some hints, but I suspect that part of the design of the disk backup sets (oops, disk media sets) is to permit a common unified format with (to be implemented, hopefully) internet backups. Russ
  7. rhwalker

    Testing 8.2 without uninstalling 6.1

    Disable your 6.1 schedules so that 6.1 doesn't fire up a scheduled backup. 6.1 can't run at the same time the engine is running because they both want to grab the hardware (unclear from you minimal post what type of hardware/media you have for your backups - tape, optical, disk, etc.). Russ
  8. rhwalker

    Media versus thorough verification

    No. Read my explanation again. The two types have entirely different purposes. Use the right tool for the job. The only time I would consider comparison verification (which is what I believe the operation should be named, for clarity) is for backup of a quiescent volume. Examples would be: (a) a share that has been taken offline so that no users or applications can modify the volume; ( an archive volume; © a volume that is being recommissioned from storage; etc. Almost every other case has a volume whose contents are, or may be, modified in the time between backup and comparison. It also depends on whether you trust MD5 technology and Retrospect's implementation of that technology. That's why you need to establish a backup policy and then test thoroughly against that backup policy's requirements. Russ
  9. rhwalker

    Restoring files and folders

    Without more information, it's hard to tell whether your backup size is correct. Remember, a backup preserves history, so multiple versions of each changed file are kept. If you've been running backups into the same backup set for a while, it's conceivable that your backup set could be terabytes in size even for a source drive of 42 GB. The whole point of a backup is to be able to go back to any point in time. Russ
  10. You do understand what an "entire agreement" clause is, don't you? It's not just oral statements of a Customer Support representative - it's that the EULA can only be modified in a very specific manner: It's a bit like asking whether a stock clerk at Target has the authority to bind the corporation. That's why attorneys put "entire agreement" clauses in contracts. Russ
  11. rhwalker

    Should I upgrade from version 6?

    Yep. Extensive pre-deployment testing against our requirements. Not yet for production use. Yep, you are right. It's never passed our isolated testbed tests. Much time wasted (well, not wasted because our data hasn't been exposed). Thorough testing takes lots of planning and time. Backup on an isolated testbed, restore to isolated systems, etc., test usage. Much disappointment. Note that we only back up to tape. It may or may not work for disk-only or optical media backups - I haven't tested those because they are not part of our backup policy. And, even if (when) Retrospect 8 becomes solid, we can't use it for production until it is scriptable to coordinate with external events (coordinated stop/checkpoint/start of services for backup). Hope springs eternal ... Russ
  12. rhwalker

    Media versus thorough verification

    They do different things, and have a different purpose. One (media verification) compares the MD5 calculation of the media set contents against that calculation in the catalog (made when the backup was done). The other actually compares the source against what's in the media set, which often is not possible if files changed since the backup was made. Consider the case of constantly-changing logfiles. A comparison verification is worthless, and cannot ever be done because the source file will always be different. Personally, I would prefer that MD5 verification be called exactly that, because that's what it is, but some users may not understand what the MD5 calculation is, or why it's useful, etc. Russ
  13. rhwalker

    8.2 catalog recovery

    Nope. I was trying to push the OP into a direction where some of the members of the media set (the good ones) could be used to extract whatever was possible. It was also unclear to me, because this thread has gotten long, whether the problem was grooming caused - perhaps the catalog (or a saved catalog) worked well enough for a transfer (copy). From everything I have seen, if the set can be groomed, then the integrity of the catalog is OK. I was using the term "bit rot" to cover the mysterious and still unknown causes of catalog corruption that continue to happen. Who knows? AFAIK, it's mystery garbage blocks from space. I'm willing to chalk it up to bugs that have subsequently been fixed as 8.x has matured, and I'm not sure that it's productive (or even possible) to have a post-mortem analysis of what the cause was. At this point, I still treat 8.2 and its predecessors as an evolving alpha, beta series, not yet solid enough for my data, at least from my tests, and it takes a LOT of my time to shake out a release with regression testing. Perhaps with the 8.9 or 9.1 release... Hope springs eternal ... Agreed, as long as it's not my time that's involved. Well, that's something to try, but I haven't seen anything in this thread to indicate that the problem is filesystem related. A concern to me for all of this testing is that some have become so accustomed to engine crashes (and, rarely, kernel panic caused by Retrospect, despite what Robin may think), that people may be hitting that "power reset" button, which upsets Unix a lot, even considering journaled filesystems. In the absence of a ZFS-type filesystem, garbage can occur anywhere in such a scenario, which is why I do my testing on an isolated testbed, away from my data. Russ
  14. rhwalker

    Should I upgrade from version 6?

    That's not true with backup software. Or perhaps my data is more precious than yours. Because of our backup policy and data retention needs, I can't afford to move to a backup solution until that solution is rock solid. "Something" may be corrupting data on which you depend, and you won't know about the corrupted / missing data until years down the road when you need it. Backup software is in an entirely different class from games and "normal" applications. It's database software, and you can't go back in time to get something that doesn't exist any more because of defects in the software. The bar is very high. No backup is better than unreliable backup. At least with no backup, you know where you stand and adopt other options. Russ
  15. rhwalker

    8.2 catalog recovery

    Nope. That thread is for the Windows code base, which is different from the 8.x code base. They really haven't converged quite yet. Actually, I suspect that might be the problem. Issues have been seen with bit rot carried forward from 8.0 into 8.2. Let me suggest a different approach, if you can pull it (or a variant) off. Start a new media set, try to transfer (oops, terminology change with 8.x - "copy") from the older media sets into the new media set. That will do a catalog creation on the fly for the new media set. It may be that Retrospect is confused about the old media sets because of their ancestry. Get the mindset that you have a database (that's what the media sets are) with a possibly-corrupted database index (that's what the catalog is), and do database operations to move the data from one database to the other. Then, once you've got a good database with a good index, it might be possible to Groom, Steve. Russ
  16. rhwalker

    error -519

    Many users think that it "should", but it doesn't. This has been discussed for many years here in these forums. As Steve Maser indicates, Retrospect does have a "Wake on LAN" setting that is supposed to wake sleeping Macs (some models), but, I believe that it only works for "proactive" backups, not scheduled backups. (see page 41 of the Retrospect 8.2 User's Guide). See the user's guide (page 33 and pages 128-131) for a discussion of the differences of the two types (proactive vs. scheduled) - in short, a "proactive" backup is for computers, such as laptops, etc., that appear and disappear from the network, and Retrospect continually polls the network to try to find machines to back up. What many users do, as a workaround, is to set the Energy Saver settings on the laptop/desktop to wake the computer up just before the scheduled backup time for that computer. Some people have even written elaborate scripts to wake up each computer on the LAN at the right time. Such an approach only worked with the older version of Retrospect, which was scriptable and could interact with external scripts. Retrospect 8.2 is not scriptable. Other than stability, this is the most glaring missing feature of Retrospect 8, in my opinion, and makes it impossible to coordinate backups of a server with stopping/checkpointing/restarting services for backup. Russ
  17. rhwalker

    Should I upgrade from version 6?

    You are either a brave man to use that in a production environment or your data is not very important. Russ
  18. rhwalker

    Restoring files and folders

    That's not a problem to be attacked by restoring files, and there would be an issue as to specifying what you consider "the essentials" to be. It would be better for you to troubleshoot the problem rather than restoring files blindly. Russ
  19. rhwalker

    Restoring files and folders

    It all depends on what you want to do. If you want to restore individual files (as you might want if just a few files were accidentally deleted), restore files. If you want to restore an entire volume (as you might want to do if a disk was accidentally erased, or if you had to replace a disk, etc.), then restore the entire volume. Does that help? Or perhaps I don't understand the question. Russ
  20. rhwalker

    Source volume marked as offline

    Somehow, the Drobo appears to have become unmounted and remounted, and now appears at a different mount point (regardless of what you think). Check out /Volumes with Terminal, and also do a "mount" command in Terminal to see what is mounted where. No, not if they were mounted differently. Perhaps did you unmount and remount the volume in the Finder? That's a common cause of confusion (to Retrospect and to the user). Have you tried a reboot? Search these forums for a discussion. This point has been discussed many times. Russ
  21. rhwalker

    Should I upgrade from version 6?

    That's very interesting because Retrospect 8.2 beta 1 was released on June 10, 2010 (4.5 months ago), Retrospect 8.2 beta 2 was released on June 29, 2010 (4 months ago), and Retrospect 8.2.0 (build 399) itself was released July 27, 2010 (three months ago). Russ
  22. The Retrospect 8.2 design is unchanged in this respect. However, the terms did change: "Selectors" are now "Rules" "Subvolumes" are now "Favorites". As long as the design remains unchanged, the behavior will not change (except due to bugs). Russ
  23. This has been discussed at length in these forums over the years. Because of the design of Retrospect, it does a full recursive tree walk of the filesystem tree, then passes the list of files to the filters ("selectors", now known as "rules" in Retrospect 8) to decide which files will be candidates for backup, and then, after sorting that huge list (one of the reasons that Retrospect needs lots of RAM) so that it can be evaluated against the contents of the backup set (f/k/a/ "storage set" in the early versions of Retrospect, now known as "media set" in Retrospect 8 new-speak), uses the "matching" criteria (whether files changed from versions in the backup set, etc.) to decide whether the files are to be backed up in the current session. All of that takes time - it's CPU intensive, I/O intensive, and RAM intensive. Such a strategy was fine when volumes were small and didn't have gazillions of files. The only way around it with the current design is to segregate your changing files into Retrospect "subvolumes" ("favorites" in Retrospect 8 new-speak) so that only those "subvolumes" get scanned (by the magic of Unix "chroot" - see the man page for details ("man chroot" in Terminal, without the quotes)). And don't expect Retrospect 6.1 to change - it's dead, Jim. Russ
  24. No, that addresses a different issue - whether two apparently-identical copies of a file at different locations (different directories or computers) should be backed up multiple times. That setting shouldn't have any affect on this particular issue, which is simply a question of what metadata is checked when Retrospect decides whether changes have been made. It's possible that the actual NTFS timestamp (which is much more specific and more granular than the timestamps displayed in the GUI) isn't matching what is reported in the backup. The way to test this would be to see if this replication occurs on a different filesystem. Another possibility is if "Robocopy" somehow changes metadata that is not being reported. If you have some utilities to view the full metadata for the file(s) at issue, you might investigate in that direction, or perhaps suspend "Robocopy" operations for a few days while you observe the results. Russ
  25. rhwalker

    Should I upgrade from version 6?

    No. No. Here is the link for the Retrospect 6.x forum: Desktop, Workgroup and Server for Mac OS X (Pre-8.0 versions) And, when you repost, it would be very helpful to provide some specifics: (1) exact version of Retrospect 6 (6.x.x) (2) exact version of Retrospect client (x.x.x) that sees the problem (3) hardware and Mac OS X versions for affected computers and Retrospect server (4) whether this is seen on all clients or just some, and the differences for those clients. (5) some information about your network infrastructure Russ
×