Jump to content

Cygnis

Members
  • Posts

    152
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Cygnis

  1. Have you tried updating your script(s) to point to the 'new' volume?
  2. So, you have been choosing the folder containing your .rdb files as the source for your tape backup script? If so, I expect that the resulting tape backup set would only be aware of the .rdb files, not their contents. A better option would be to do a monthly "Transfer" operation rather than "Backup" or "Archive." This will transfer the *contents* (individual files, snapshots etc.) of the disk set, resulting in a tape set that can be searched for restoring individual volumes/files/folders. See the Retrospect manual's sections on "Transfer Snapshots" and "Transfer Backup Sets" for more info about this type of operation.
  3. Do you have the drives selected as part of a "Source Group"? If so, has the list order of the group changed? (Modifying this would be one way to try changing the order back.)
  4. Thanks Robin! Was able to find what I needed using the workaround.
  5. Hi all, The online hardware compatibility database (http://www.retrospect.com/hardware) used to display the minimum Retrospect version required to use each device, but no longer. When I click any device's search result, it no longer goes to a page specific to that device that includes the version information, but instead bounces to http://www.roxio.com/enu/support/retrospect/default.html Will this be fixed? Or am I looking in the wrong place now? Thanks!
  6. Have you installed the "Retrospect Client" application on the PC you want to restore to?
  7. (Sorry, clicked the wrong "Reply" button: my question is directed at the original poster, not rhwalker): Do you have "Back up file system security information from servers" enabled (under "Security" in the Backup options)? Have you tried disabling it? We were having the same issue at work (on a Win 2003 server) before disabling that option. (We've left the "Back up FOLDER security information from servers" option enabled without any problems.) I would assume that failing to back up file security information could have side-effects when restoring certain types of data, so I can't guarantee it will be an ideal solution for your situation.
  8. Yeah, I'll probably just burn them to disc (outside of Retrospect) at some point, and then either remove them from my PC or exclude them from my Retrospect backups. Unless I get the time/inclination to test a bunch of other file types, I'll probably just leave software compression off in future. This isn't a big inconvenience to me; I just wanted to gain an understanding of what was going on, and share my experience in case others encounter the same thing. Thanks to everyone for your responses.
  9. As mentioned above, I also tried a 'Disk' (hard disk) backup set, and the same occurred. So yeah, the use of optical media was apparently not a contributing factor. If I get time I'll also try a 'File' backup set as per your suggestion. My guess is that the same will occur again, but there's no harm in trying. That definitely makes sense. Thanks for the info (and for the link/mention of RLE encoding). No, but I suspect that the files' contents are highly compressed. They are large application/OS installation files downloaded from Microsoft, which I'd expect to be compressed as much as possible to conserve their server bandwidth (and make the downloads smaller/faster for their customers).
  10. Understood. What surprised me wasn't the fact that the data didn't compress, but the fact that it grew (instead of being stored at its original size), and rather substantially (2.0 -> 4.4 GB in one case). Will definitely read up on compression algorithms as per your suggestion. Thanks! Does anyone know the name/type of the algorithm used by Retrospect? Cheers, will give that a try.
  11. I'm not personally familiar with this situation, but here are a couple of older threads that appear relevant: http://forums.dantz.com/showtopic.php?tid/32952/ http://forums.dantz.com/showtopic.php?tid/33959/ If I understand correctly, the errors appear to suggest a problem with your second backup set media. I assume you are using the same disk each time (i.e. not spanning the set over multiple disks)? Would it be feasible to start a new "offsite 2" set on a new disk, and see if the problems go away? (Alternatively, you could delete the current one and try using the same disk for a new set, but that is more risky because it only leaves you with one offsite copy of your data until the new set has been generated.) The fact that your "offsite 1" set is okay is a good sign, but not a guarantee that the data will be restore-able. Do you ever do 'test restores' to check the reliability of your sets?
  12. Thanks for the info. Is Retrospect unique in this regard? Because when I compress one of these files to ZIP or RAR format, its size decreases (only slightly, but at least it doesn't increase!). No, none of my usual sets or these test sets are encrypted.
  13. According to the device support database, yes: http://www.retrospect.com/supportupdates/technical/retrospect/search/?q=tl4000 Yes, but it requires the "User Initiated Restore" add-on, and only works for backups to hard disk (not tapes).
  14. Is this also the case when restoring a Macintosh system installation?
  15. Just tried the same test with two new Disk backup sets on my Iomega USB external hard drive. Same result! There are 6.31GB of .rdb files in the "compression OFF" backup set, and 9.04GB in the "compression ON" set. This should eliminate the DVD burner as a possible contributing factor. I restored the files from the "compression ON" set, and (thankfully!) they came back at exactly their original sizes. Any thoughts?
  16. Another point that may be of interest: When I go to Configure -> Backup Sets, each member (disc) has 4.4GB in the "Used" column, suggesting that Retrospect is writing a full 4.4GB to each disc, even though that 4.4GB is holding less actual data. Could the software compression process be adding in some kind of 'filler' data?
  17. Hi all, I noticed that Retrospect was writing as little as 2.0GB per disk to my DVD+R media, particularly when backing up some application installation files. As it turns out, the "software compression" option was to blame. Here is how I tested it: (1) Created two new Optical backup sets. (2) Selected 6.4GB of data, consisting of application installation files (mostly downloaded from Microsoft's website). (3) Backed up the same data to each of these two sets, one with "Software Compression" enabled and one without. Result: The first set (with compression OFF) wrote 4.4GB to the first disc, then 2.0GB to the second. The second set (with compression ON) wrote 3.1GB to one disc, then 3.0GB to a second, then 0.3GB to a third! I'm guessing that install files aren't very compressible, but at worst, shouldn't they simply be stored at their original size? Why on earth would they end up requiring MORE space with compression enabled? System specs are as follows: - Retrospect Professional 7.7.325 (with 7.7.3.102 update) - Windows XP with Service Pack 3 - Verbatim DVD+R 16x media - Optiarc AD-5560A 8x DVD +/- R burner (not officially supported, therefore custom configuration used) - Dell Latitute D630C notebook with 2.4GHz Core 2 Duo processor, 4GB RAM, 200GB 7200rpm HDD Any info would be appreciated. I can live without the compression, but I'm curious to know what causes this issue (and if it's due to any error on my part). Thanks in advance.
  18. Thanks for the detailed response! Much appreciated. I was more concerned about tape longevity/health than workflow interruptions, but I guess they're designed to be written and re-written many times over, so I'm probably just being excessively paranoid. Good to know about the differences between the types of verification that are possible via scripting, too. (For some reason, I thought that a full compare- which is the same as "thorough verification," right?- was only possible at the time of backup. Nice to know that this isn't the case, and also that the MD5 option is a viable alternative.) Cheers!
  19. Hi all, I've been testing the Backup process using multiple sources. Whether I use 'Source Groups' or individually select each source, the following seems to occur: If I have two sources, "Folder A" and "Folder B", Retrospect seems to do the Backup tasks in this order: - Copy Folder A - Compare Folder A - Copy Folder B - Compare Folder B My thinking is that it would be better for the destination media (especially when using tape) if it did it this way instead: - Copy Folder A - Copy Folder B - Compare Folder A - Compare Folder B That way, it is doing all the writing in one pass, then all the comparisons in one pass. Is there a way I can make it behave like that? Or, am I wrong in thinking there is any benefit to doing it that way? (Note that I intend to back up several sources at a time, not just 2. All sources will be local disks, not client machines.) Thanks very much.
  20. Hi all, Let's say I have a tape backup set with Matching enabled, and that my latest backup includes some matched files that do not need to be re-copied. During the comparison/verification stage of the backup, does Retrospect prompt me to insert the older tape(s) for the purpose of verifying the files that were already copied? Or does it only try to compare/verify the newly copied files, meaning I don't need to insert the older tapes? Thanks very much.
×
×
  • Create New...