Jump to content

Don Lee

  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Don Lee

  1. I'm getting this error: Date: 5/23/2017 9:40 AM Can't use Open File Backup option for OS (C:) on TLOlibrary, error -3043 (the maximum number of Snapshots has been reached) Windows 7 for the Retro backup machine. Windows 7 for the client. NTFS FS backed up. Retrospect Trial. (windows v12) What does this mean? The backup seems to run anyway, but is it somehow incomplete? How do I "fix" it?
  2. Just for grins, I restored a file using the client GUI. This was just a test. I restored to a new folder at the root level of the C drive. (The client does not provide for a "subvolume" def?) When I did the restore - of a file that was about 8K - it took quite a while. It restored two things in my new folder. One was the file. The second thing was a folder called "Windows" that had several folders in it, and many subfolders. These were apparently "VSS" related. What's up here? Anyone care to explain what the extra gink was? When I did the same restore from the server GUI, and used a subvolume for the target, I got just the desired file restored, and it took just the brief time expected. Also, when I went to the server GUI and tried to define the "new folder" as a subvolume, Retro would NOT do it. It would just ignore me. I could define other folders as subvolumes, but not the folder I had created by the client to act as target for the restore. When I RENAMED the folder, the server GUI let me define it as a subvolume. What's up here?
  3. Don Lee

    Error "-3045" stumps me

    I am backing up a laptop Windows 7 system with a Windows Retro 12 server. Retro whines in the backup: +Normal backup using Weekly_laptops at 5/12/2017 2:47 PM (Execution unit 2) 5/12/2017 2:47:54 PM: Finished scanning backup set data files To Backup Set Weekly_Laptops... [*] T-7: VssWSnapVolume: DoSnapshotSet failed, winerr -2147212513, error -3045 Can't use Open File Backup option for OS (C:) on PASTORS-NB, error -3045 (there is insufficient storage space to complete the operation) I went to the Retrospect KB, and retrieved this: https://www.retrospect.com/en/support/kb/3045_there_is_insufficient_storage_space_to_complete_the_operation_and_3405_can_backup_system_state However, I followed the directions, and there are three partitions, none of which called the "System Reserved" partition. There is a small (35 MB) unnamed partition, a "Recovery" partition, and the C: drive. I tried "deleting the log" from the "recovery partition, but that did not fix the problem. I presume that the registry (system state) failed to back up, which means that the "bare metal" restore would not work. This is something I need. What's up with this? Can I fix it?
  4. Don Lee

    New Windows user wants advice

    Retrospect Windows server installs two programs. One is called "Retropect", and the other called "Retrospect Dashboard". The "Dashboard" is limited in what it can do. To actually manipulate the retro behavior, you have to fire up "Retrospect". If you use the "Relaunch" button in the upper right corner of the "Dashboard", it does not seem to interrupt running activities. Exiting "Retrospect", on the other hand, *does* seem to kill off anything that is currently running. After exit, the activities will "auto-launch", but the activities, at minimum, are interrupted. I run Retrospect as "administrator" of the "domain". I also told Retro at install to use that login. When I log in as that same user, and launch "Retrospect" it whines at me that I am about to kill stuff off. If I say "OK", nothing happens. If I launch the "Dashboard", and hit "Relaunch", I get Retrospect, as expected. Strange, but workable. Odd, but workable.
  5. Yes. That is what I see. However, unlike the Mac, the currently running scripts get killed and restarted. On the Mac, the executions continue without interruption.
  6. Don Lee

    Another New Windows User, advise on DR

    Cool. I did an experiment - a restore of a complete volume does indeed restore a bootable volume. I can do this from both the windows and Mac retro server. I still don't have much information on HOW Retro does this. Does it back up the "secret" partitions only if you choose "computer" when backing up? My experiment was only backing up the C: volume, and it still boots. (I didn't check for partitioning, only boot) Open files option? The backup I did to restore the bootable volume was done by a Mac server that does *not* have the "open file" feature. Will that fail sometimes without that feature? (that would be a real surprise - bare-metal restore without "open file" feature fails(!)) The idea that the partitioning should be done "manually" by me before doing the restore makes little sense. If the "secret" partition is saved by Retro, only Retro knows how big it is, and what needs to be in it. What I have seen is that if I partition the disk myself, Retro will honor my partitioning. How do I size the partition, and select a partition type if I know nothing about it? I have more questions about this, but at least I have demonstrated one path to making it work. Thanks for posting.
  7. Don Lee

    Another New Windows User, advise on DR

    That reminds me - I've seen nothing in the DR documentation on how the partitioning is done. Is there machinery to let me choose EFI or MBR partitioning? MBR is essential for the oldest systems, while the newer is essential for newer ones - especially big volumes.
  8. Thank you all for your help and replies. For my money, I am still toying with running the Mac server, because as far as I can tell, it is 100% of the functionality. (almost: no disaster recovery CD creation, but I already did that with the evan retro) For launching retro on Windows while running, going to the "dashboard", and hitting "re-launch". It's not elegant, but it works reliably. I have also confirmed that if I quit the GUI, despite claims that activity will "stop", my scripts run. I **think** I have a working installation that I understand. ;->
  9. Don Lee

    Another New Windows User, advise on DR

    I can't quite get a complete answer to how - exactly - Retrospect restores the hidden "boot" partition on the restored disk, nor what I have to do to properly prepare the disk for that restoration. I gather that I simply add a "C:" volume to the disk, and Retro auto-magically creates the boot volume and its contents, though no explicit option or action causes it. It is apparently a side-effect of choosing " entire volume" for restoration. It also appears that it does not matter if the Retro server is Mac or Windows, the restore does the same thing and works. I am trying this theory out. THere is no substitute for testing. ;-> I would love to get some confirmation, though. Thanks,
  10. Don Lee

    New Windows user wants advice

    Many thanks. I am learning. Although you kill of "Retrospect" if you log off Windows, it seems to re-start in the background somehow. If I start Retrospect (as the same user - administrator) I get a dialog saying "Retrospect is already running under another user." Odd. I also see that Retro HAS run my scripts, so some sort of "background" execution is happening. Unlike the Mac, I don't understand how to manipulate Retro while running. The dialog warns me that Retro will be stopped and brought up under my User ID. I hit OK, though, and it doesn't appear. Since Retro has lots of Windows users, there are undoubtedly ways to do what I want. I just have not yet learned them. So far, though, I'm tempted to just go with a Mac. That - I'm comfortable with.
  11. Sorry - my mistake. I am running Retro 12 Mac almost everywhere, but recently installed my first Windows installation - Windows 12. To recap - I need to update to Retro Mac 13 (or better - 14 is pretty new. ;-> ). I may also get to test this on Retro Windows 12 at the new installation.
  12. i need to upgrade to Retro 13 so I can see if this is fixed. I have installed Retro 14-Windows at one of my clients. I may have an opportunity to try it there. (No good deed goes unpunished - once you get it working reliably, no one ever upgrades again. ;-> )
  13. I have seen this behavior since v9, and it seems to be rare, but about the same. You can see my post about this in: http://forums.retrospect.com/index.php?/topic/151548-verify-vs-copy-and-data-errors/ ( and http://forums.retrospect.com/index.php?/topic/151193-error-in-the-log-what-does-it-mean/ and http://forums.retrospect.com/index.php?/topic/150803-what-does-verify-error-mean/ ) In short, I get MD5 errors in media sets that remain even after the media set is copied, and seem to be repeated if the same file is backed up again. It is as if there is something about the file that the MD5 algorithm can't handle correctly. A verify of the media set will reliably complain of the MD5 error. A restore of file with the MD5 error will succeed without error, and if I copy the media set, the copy operation will see no MD5 error, but the resultant copied media set will show the MD5 error on the same file when I do a verify on the copied media set. I would normally blame this on hardware - bad disk, bad cables, flaky hardware, but I have seen this on several disks and several computers, and the problem does not appear to be hardware. The pattern appears to be a software problem in MD5 generation (or verification). The error usually happens on files with very long "garbage" file names. (generated by some sort of hash) I can't pin this down, nor reliably reproduce it. If I can, I'll do so.
  14. Given my difficulty in the past to reproduce this on command, verifying the fix would be non-trivial. What is clear is that if I stay away from the "recycle" option on the target media set, things appear to work. The bad part is that what I want to do is "rotate" my media sets this way. At the end of month, I want to copy the current set to ->> "last" set and recycle the current set. The combination of the "recycle target" option and "recycle source when done" options does just what I want. Unfortunately, as it stands, if I use both of those options, the source gets recycled, and the target (copied) set ends up truncated and useless - sometimes. I lose BOTH sets - randomly. I can't take that risk, so I have been running with multiple scripts to zero out the "last" target, zero out a "safety" target, copy from current to the safety target, copy from current to "last" target (with potentially dangerous options), then go back later to recycle the "current" set, which usually has had at least one backup run on it since the last copy, making comparisons for the copy suboptimal. As it stands, I think I can do my rotations with two scripts, rather than 4, but it would be so much better if I could do it - reliably - with one. Thanks for your help.
  15. I can confirm that my testing has run cleanly for the last new months. It appears that the "recycle target" option at start of script causes the problem. This means that I can do what I want by setting up two scripts - one to recycle the target media set, and then another to actually do the copy. Any progress on getting this fixed?
  16. For those of us considering upgrading to v13, the system requirements at retrospect.com have not been updated to say what the requirements are for the console or engine...
  17. Don Lee

    MD5 digest calculated incorreectly??

    I'm not so sure it's a fatal problem. It's a warning, and does not seem to affect the data when restored. I suspect that the hash that Retro generates includes the name and meta-data, so checking that hash against the "standard" tool is probably not valid. That said, I agree it should be fixed.
  18. This is indeed a tough problem. You have to face up to the fact that you only have a small amount of data. 1.5T these days is just not that much. A 3 TB drive costs what? $150?? For $300, you can set up a RAID mirror, and put all your data there, or put your data on one drive and use the other for the retro backup. Every 5 years or so, copy the data to a new drive. Like it or not, that works well. Not only does it save a lot of swapping, it allows quick and easy organization of the data. Another $100 every 5 years is a small price to pay for not having "longevity". Just my opinion. YMMV.
  19. 16 is a lot. 8 could be a lot. Being able to run more than 1 - like 2 - is wonderful. However, it's not often that more than 2 or 3 are of real advantage. If you get several threads either reading or riting to the same device/disk, you end up spending all your time seeking the head. Other scenarios also limit the actual amount of "parallelism" you actually get. Each thread can burn a lot of memory and/or other resources. I'd be inclined to limit the threads to 2 or 3, unless you have a good plan, and a good reason.
  20. I hit an assert just now. I had been dumping stuff to DDS tape, and was done. My tape drive is a USB DDS HP Dat-72 drive. I powered down the HP DDS tape drive, and engine asserted. I can send the whole log and whatever other info required if this is something worth chasing. The start of the assert log is: ********************************************************************^M ^M Mac OS X OS Type: Darwin OS Release: 12.6.0 OS Version: Darwin Kernel Version 12.6.0: Wed Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 Machine: x86_64 Model: Macmini6,1 NCPU's: 4 PhysMem: 0x400000000^M Application: /Library/Application Support/Retrospect/RetrospectEngine.bundle/Contents/MacOS/RetrospectEngine, version Exception occurred on 2/26/2016 at 3:52:14 PM^M Error info: Assertion failure at "module.cpp-1063", on threadID 0x103604000 Signal no: 30 Assertion Error no: 00 Sig Code: 00 Fault Addr: 0x000000009267D686 -- "mach_msg_trap" Thread ID: 0x000000000180D040, Name: rax:0x000000000100001f r8:0x0000000000000107 r12:0x0000000000000003 rip:0x00007fff9267d686 cs:0x0000000000000007 rflags:0x0000000000000206 rbx:0x0000000000000028 r9:0x0000000000000000 r13:0x00007fff5fbf9c10 rsp:0x00007fff5fbf9ba8 rbp:0x00007fff5fbf9bf0 rcs:0x00007fff5fbf9ba8 r10:0x00000000000003b0 r14:0x0000000000000107 rsi:0x0000000000000003 fs:0x0000000000000000 rdx:0x0000000000000028 r11:0x0000000000000206 r15:0x00000000000003b0 rdi:0x00007fff5fbf9c10 gs:0x0000000000000000 Module Function + offset into function Args _______________ ________________________________________________ _______________________________________________________________________ libsystem_kernel mach_msg_trap +0xa libbedrock.dylib TAddress::Dereference(unsigned int) cons +0x21 libbedrock.dylib TStackIA64::backtrace() +0xf6 libbedrock.dylib TStackBase::BacktraceMach(unsigned int, +0x34 libbedrock.dylib DebugHandler::generateExceptionReport(__ +0x183 libbedrock.dylib DebugHandler::SignalHandler(int, __sigin +0x2f libbedrock.dylib DebugHandler::DebugHandler() +0x0 libsystem_c.dyli _sigtramp +0x1a CoreFoundation __CFRunLoopServiceMachPort +0xc3 CoreFoundation __CFRunLoopRun +0x436 CoreFoundation CFRunLoopRunSpecific +0x122 CoreFoundation CFRunLoopRun +0x61 libmeson.dylib cfRunLoopInTask(int) +0x13b libmeson.dylib doTask(long long, long long (*)(...), Mo +0x7ca libmeson.dylib TThread::TaskCall(long long, long long ( +0x515 libmeson.dylib TThread::CFRunMsgLoop(int) +0x36 libmeson.dylib doTask(long long, long long (*)(...), Mo +0x7ca libmeson.dylib TThread::TaskCall(long long, long long ( +0x515 libmeson.dylib mesonGo() +0x14d libmeson.dylib doTask(long long, long long (*)(...), Mo +0x7ca libmeson.dylib TThread::TaskCall(long long, long long ( +0x515 libmeson.dylib Meson(int) +0x11c RetrospectEngine main +0x573 RetrospectEngine start +0x34
  21. I'm seeing this problem again. Proactive scripts scheduled with the target time long past, and the status "not yet determined". They don't run until I restart the engine. I think there is a bus in there somewhere.
  22. I have been manually copying my media sets that appear to have suffered from the problem described here: http://forums.retrospect.com/index.php?/topic/150511-nasty-bug-scheduled-copy-media-set-only-copies-fraction-of-data/ When I copied the media sets, I found that although the reported number of files and the size of the resultant media set looks correct, when I look at the target copy and "retrieve" the older backups, there is *nothing* there. This may be a more serious bug than that described in the previous report. I am running (console and engine) I plan to try doing the copy via "copy backups" (and copy all backups) and maybe upgrade to 11.5.2, but there is nothing in the release notes that indicates that this has been fixed. This is new, bad, behavior not present in 10.5. I'll report back.
  23. It has been a while…. As I recall, this was a hard error, and easy to reproduce. Sorry i did not follow up and report my results with that "minor update". The fact that I did not report back with "still busted" testifies to a successful fix. Unfortunately, I don't remember exactly what version fixed it. You should be able to determine that from the datestamps on the updates. It is also fixed in v12. I copy media sets commonly, and I only lose files when I use "recycle target at start". I have an outstanding bug on that one, but that's a little harder to reproduce.
  24. Don Lee

    5 minute log rotations?

    FWIW, I killed the client (including a "kill <pid>" on retroclient) and the 5 minute rotations are no longer happening - for now, at least.
  25. This is a partial "ls -la" in / on my client machine running 10.7.5. Retro client 12.5.0 (111). -rw-r--r-- 1 root wheel 284 Jan 14 16:43 retroclient.log -rw-r--r-- 1 root wheel 199 Jan 14 16:38 retropds.log.0.log -rw-r--r-- 1 root wheel 199 Jan 14 16:33 retropds.log.1.log -rw-r--r-- 1 root wheel 199 Jan 14 16:27 retropds.log.2.log -rw-r--r-- 1 root wheel 199 Jan 14 16:21 retropds.log.3.log -rw-r--r-- 1 root wheel 199 Jan 14 16:16 retropds.log.4.log -rw-r--r-- 1 root wheel 199 Jan 14 16:10 retropds.log.5.log -rw-r--r-- 1 root wheel 199 Jan 14 16:04 retropds.log.6.log -rw-r--r-- 1 root wheel 199 Jan 14 15:59 retropds.log.7.log -rw-r--r-- 1 root wheel 199 Jan 14 15:53 retropds.log.8.log -rw-r--r-- 1 root wheel 199 Jan 14 15:48 retropds.log.9.log drwxr-xr-x@ 62 root wheel 2108 Apr 13 2015 sbin lrwxr-xr-x@ 1 root wheel 11 Apr 13 2015 tmp -> private/tmp drwxr-xr-x@ 12 root wheel 408 Apr 13 2015 usr lrwxr-xr-x@ 1 root wheel 11 Apr 13 2015 var -> private/var humor:/ donlee$ cat retroclient.log Client version is 2016-01-14T16:43:30: FSBuildExcludeList: skipping /Library/Preferences/retclient.dat 2016-01-14T16:43:30: FSBuildExcludeList: skipping /Library/Preferences/retclient.dat 2016-01-14T16:43:31: FSBuildExcludeList: skipping /Library/Preferences/retclient.dat humor:/ donlee$ This is the same client that seems to fail from time to time on scheduled backups with "client reserved", when it should not be. What's up with the 5-minute log rotation, and what's "retclient.dat"? Looks like a typo to me.