Jump to content

Search the Community

Showing results for tags 'Instant Scan'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Announcements, News and Resources
    • Latest News
  • Windows Products-Retrospect
    • Professional
    • Server, SBS and Multi Server
    • Device and Hardware Compatibility-Windows
    • Exchange Server Add-On Support
    • SQL Server Agent
    • Linux, Unix and Netware Clients
    • Express for Windows
    • Product Suggestions-Windows
  • Mac OS X Products-Retrospect
    • Retrospect 9 or higher for Macintosh
    • Retrospect 8 For Macintosh
    • Retrospect 6: Desktop, Workgroup and Server for Mac OS X
    • Device and Hardware Compatibility-Mac OS X
    • Linux Clients
    • Product Suggestions-Mac OS X
  • Macintosh OS 9 and Earlier-Retrospect
    • Express, Desktop, Workgroup and Server for Pre-OS X
    • Device and Hardware Compatibility Pre OS X
  • General Discussion-Retrospect
    • Networking and Clients
    • Strategy, Scripts and General Use
    • Retrospect iPhone App
  • Retrospect 8.x for Mac
  • Retrospect 6.1 for Mac
  • Retrospect 7.7 for Windows
  • Retrospect 7.6 for Windows
  • Retrospect Express
  • General Discussion

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 9 results

  1. Hey Everybody— Have I missed something about APFS/High Sierra and Instant Scan? Or am I just having an isolated issue? I'm noticing it takes an hour to scan my 1 million+ files on my MBP, and that Instant Scan doesn't appear to be doing anything on my machine. Checking the Engine logs does not show the usual "Using Instant Scan..." entry for my machine. I can provide further observations and log info if need be, but first I just wanted to see if this was something already known/common. I'm using Retrospect v14.6 of server and client. Thx, Fred
  2. The Instant Scan FAQ (http://www.retrospect.com/en/support/kb/retrospect-instascan-faq) does a good job of explaining how Instant Scan is implemented and describes some of its problems and limitations. The main problems described are: 1. RetroISA can use a high CPU load. Even after the initial scan, the service's use of CPU can spike degrading the performance of other applications. 2. Recently modified files may be missed from a backup if the service hasn't gotten around to scanning them. Additionally, I've had the RetroISA service block a chkdsk /f because it had an open handle on the volume. I wouldn't be surprised if it also interfered with "safe removal" of an external drive. I don't know about the Macintosh platform, but I think this can be done better on Windows. The FAQ indicates that Instant Scan only works on NTFS formatted drives in Windows because it makes use of the USN journal. Since the USN journal is a requirement, doing all this background scanning is largely unnecessary. Background: The USN journal maintains a list of changed, added, deleted and moved files. The old way of doing an incremental backup (in general for any backup application) was to scan the entire disk and compare against the backup catalog looking for changes. The USN journal removed this need. Instead, a backup application only needs to check the timestamp of the last backup, then read the USN journal from that time on. Only if the USN journal wrapped does a full scan need to be done. I've done tests with a different backup product on a 6 TB disk that had millions of files. Time to scan without USN journal: 2 Hours Time to scan with USN journal: 5 minutes This other product does not do pre-scanning like Retrospect's Instant Scan. My point is that just using the USN journal as it was designed offers a huge benefit and you avoid the problems that Instant Scan currently imposes. However, I can see some benefit to doing a pre-scan. In the case of the very first backup, a full scan would likely be required without Instant Scan. So, my recommendations for Instant Scan improvement on the Windows Platform as follows... Keep the RetroISA service, but offer different levels of Instance Scan performance options. 1. Normal: After detection of a new fixed disk, RetroISA should do a full scan saving the cache data as it does now. In this mode, RetroISA should not do any further background scanning of the volume after the initial scan. This immediately eliminates the problem of RetroISA degrading system performance. It also reduces the time when RetroISA can interfere with chkdsk /f or device removal (but see below for a discussion of how to fix this completely.) Then when a backup runs, the main Retrospect application should activate RetroISA asking it to perform a refresh (and wait for it to complete). This would still be very quick in most circumstances and it would avoid the problem of newly changed files not being included in the backup. This mode would provide a nice balance. 2. Minimal: RestroISA does no scanning on its own. Scanning only occurs when a backup runs. This would be closest to the basic implementation of backing up with the USN journal. When the first full backup runs, a full scan should be done on the volume. For all subsequent backups, the backup should ask RetroISA to refresh the cache using the USN journal and wait for the results. There is no background scanning in this mode. There is no pre-scan in this mode. 3. Disabled: For those users that don't want the Instant Scan cache files on their systems. 4. Aggressive: Instant Scan operates as it does now with periodic background scanning. This would eliminate even the 5 minute wait in my previous example. One caveat is that Instant Scan should be a better citizen when doing background scanning (It should also be like this when doing initial background scanning in Normal mode.) What do I mean by being a good citizen? If the user wants to run a chkdsk /f, get out of the way. If the user wants to remove an external device, get out of the way. The WM_DEVICECHANGE_NOTIFICATION can be used to know when one of these events is occurring. An application/service calls RegisterDeviceNotification in order to receive it. Microsoft provides an example of using WM_DEVICECHANGE_NOTIFICATION to handle the case of an external device being removed. https://msdn.microsoft.com/en-us/library/windows/desktop/aa363427%28v=vs.85%29.aspx For the chkdsk /f case, things are slightly different. WM_DEVICECHANGE_NOTIFICATION is still used, but the event that is sent is DBT_CUSTOMEVENT with an event GUID of GUID_IO_VOLUME_LOCK. I couldn't find an online sample of this, but I did write sample code myself, as test, before writing this post. I would be happy to provide this code to you. I know I'm not a Retrospect product manager, but I hope you'll give consideration to making these improvements to Instant Scan. Right now, Instant Scan is a step toward of a good goal, but there's no reason why the problems it currently has need to exist. If you don't want to fully implement all suggested modes, then please just consider implementing either the "Normal" or "Minimal" mode suggestions. Thanks.
  3. Retro 10.5 engine, Retro 10.2 -> 10.5 client I run my clients with instant scan turned off. The reasons are not so important. I just upgraded one of the clients from 10.2 to 10.5, and found that the instant scan was re-enabled. For those out there with multiple clients, expecting an upgrade not to mess with the settings, this would be annoying. I don't think a client upgrade should mess with settings that the admin explicitly applied. (almost never...)
  4. Upgraded my server to Engine 10.2.0.201 yesterday. I have not yet upgraded any clients from 9.0.2. I noticed that my system log was getting full of messages from RetroISA: Jul 18 16:39:36 %%SERVERNAME%% com.retrospect.retroisa[7334]: | ISAVol::doIsaTreeChanged: start update on volpath "/Volumes/Server HD/", 7/18/2013 4:39:36 PM Jul 18 16:39:36 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> ISAVol::CheckPrivatePathOption: PmcGetPrivate = 0x0 Jul 18 16:39:37 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:39:37 %%SERVERNAME%% com.retrospect.retroisa[7334]: ISAVol::doIsaTreeChanged: starting pass four - rescan 4 folders for "/Volumes/Server HD/", 7/18/2013 4:39:37 PM Jul 18 16:41:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:41:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: | ISAVol::doIsaTreeChanged: start update on volpath "/Volumes/DATA1/", 7/18/2013 4:41:30 PM Jul 18 16:41:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> ISAVol::CheckPrivatePathOption: PmcGetPrivate = 0x0 Jul 18 16:41:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:41:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: ISAVol::doIsaTreeChanged: starting pass five - update 1 folders for "/Volumes/DATA1/", 7/18/2013 4:41:30 PM Jul 18 16:41:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:41:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: ISAVol::doIsaTreeChanged: "/Volumes/DATA1/": rescanned 0, updated 1, consolidated 0, ignored 0 Jul 18 16:41:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:41:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: ISAVol::doIsaTreeChanged: "/Volumes/DATA1/": total time was 0 seconds (rescanning 0 seconds, updating 0 seconds, fixup 0 seconds) Jul 18 16:41:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:41:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: - ISAVol::doIsaTreeChanged: finished update on volpath "/Volumes/DATA1/", 7/18/2013 4:41:31 PM Jul 18 16:46:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:46:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: | ISAVol::doIsaTreeChanged: start update on volpath "/Volumes/DATA1/", 7/18/2013 4:46:30 PM Jul 18 16:46:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:46:30 %%SERVERNAME%% com.retrospect.retroisa[7334]: ISAVol::doIsaTreeChanged: starting pass five - update 1 folders for "/Volumes/DATA1/", 7/18/2013 4:46:30 PM Jul 18 16:46:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> ISAVol::doIsaTreeChanged: "/Volumes/DATA1/": rescanned 0, updated 1, consolidated 0, ignored 0 Jul 18 16:46:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:46:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: ISAVol::doIsaTreeChanged: "/Volumes/DATA1/": total time was 0 seconds (rescanning 0 seconds, updating 0 seconds, fixup 0 seconds) Jul 18 16:46:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> - ISAVol::doIsaTreeChanged: finished update on volpath "/Volumes/DATA1/", 7/18/2013 4:46:31 PM Jul 18 16:48:27 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> Jul 18 16:48:27 %%SERVERNAME%% com.retrospect.retroisa[7334]: ISAVol::doIsaTreeChanged: starting pass five - update 13 folders for "/Volumes/Server HD/", 7/18/2013 4:48:27 PM Jul 18 16:48:31 %%SERVERNAME%% com.retrospect.retroisa[7334]: #2> ISAVol::doIsaTreeChangedThenSave: process more changed dirs before saving scan file and so on, every five minutes. I realized that those volumes are going to be constantly changing, not only because that server is twiddling some files constantly, but also because my Retrospect Engine is on one of them, and all my Catalogs are on the other, so ISA will be constantly busy trying to keep up with file changes that are going to be skipped by my rules anyway. So I excluded those volumes in the retro_isa.ini. Here are the questions I have: (1) Does the RetroISA process have to be running on the server at all, if all the volumes are excluded? When I start upgrading my clients to Retrospect 10, and presuming that I wish RetroISA to do its thing on some of them, is there communication between RetroISA on the backup server and on the backup client, or does each client's retroclient process use the local RetroISA data, if available, for expediting the building of the snapshot? (2) If I decide that RetroISA is not a good thing for my environment, am I going to have to log into each and every one of my backup clients and disable the RetroISA launchdaemon? If so, I think we need to put in a feature request to enable a "client-by-client" configuration of features like RetroISA, as well as the ones that we currently have a Global Preference for (e.g., "Allow Clients to Turn off Retrospect Client software" "Allow Clients to Back up on demand" ... etc.) (3) Is there any way to read retroISA_log.utx? We have instructions on how to change the log size in the Instant Scan Advanced Options document ... but no way to read the log? Thanks, _rob_
  5. I note that on my server machine, the files in /Library/Application support have what I consider the wrong permissions. Most of the files here are owned by root, but the bundles and their contents are owned by the user who installed the engine. It is a security problem to allow a "normal" user to manipulate these files directly. (first cd "/Library/Application support") virtue:Retrospect sysadmin$ ls -al total 30736 drwxrwxr-x 19 root admin 646 Aug 12 19:52 . drwxr-xr-x 20 root admin 680 Apr 15 11:45 .. -rw-rw-r--@ 1 donlee admin 6148 Oct 6 2011 .DS_Store drwxrwxrwx 3 root admin 102 Apr 3 15:45 Catalogs -rwxr-xr-x 1 root admin 1488072 Aug 12 18:13 Config80.bak -rwxr-xr-x 1 root admin 7731400 Aug 13 02:37 Config80.dat -rwxr-xr-x 1 root admin 86988 Jul 12 17:21 ConfigISA.bak -rwxr-xr-x 1 root admin 86988 Jul 12 17:21 ConfigISA.dat drwxrwxr-x 3 donlee staff 102 Jul 4 10:41 RetrospectEngine.bundle drwxrwxr-x 3 donlee staff 102 Jul 4 10:41 RetrospectInstantScan.bundle drwxr-xr-x 4 root admin 136 Aug 13 02:37 RtrExec.dir drwxr-xr-x 2 root admin 68 Apr 4 13:36 RtrISAExec.dir drwxr-xr-x 3 root admin 102 Apr 3 15:43 RtrSec.dir -rwxr-xr-x 1 root admin 120003 Aug 12 19:52 assert_log.utx -rwxr-xr-x 1 root admin 6171156 Aug 13 02:37 operations_log.utx -rwxrwxr-x 1 root admin 211 Aug 12 19:53 retro.ini -rwxr-xr-x 1 root admin 18466 Jul 12 17:21 retroISA_log.utx -rwxrwxr-x@ 1 root admin 195 Jul 12 17:21 retro_isa.ini -rw-r--r-- 1 root admin 0 Jul 11 05:00 uuid_temp.log virtue:Retrospect sysadmin$ ls -al Retro* RetrospectEngine.bundle: total 0 drwxrwxr-x 3 donlee staff 102 Jul 4 10:41 . drwxrwxr-x 19 root admin 646 Aug 12 19:52 .. drwxrwxr-x 4 donlee staff 136 Jul 4 10:41 Contents RetrospectInstantScan.bundle: total 0 drwxrwxr-x 3 donlee staff 102 Jul 4 10:41 . drwxrwxr-x 19 root admin 646 Aug 12 19:52 .. drwxrwxr-x 4 donlee staff 136 Jul 4 10:41 Contents virtue:Retrospect sysadmin$
  6. Suggestion: It would make Instant Scan more palatable on a laptop if there was an option to pause it when running on battery.
  7. I have been running the 9.0.2 client on my "primary" desktop system. (Macbook Pro, Mac OS X 10.6.8) Today, with the server at the 10.1.0 (187) level, and seemingly running well, I decided to get brave and upgrade the client to 10.0.0 (174) Backups now report this: + Normal backup using daily_user at 3/15/13 (Activity Thread 1) To Backup Set v9_daily_user... - 3/15/13 3:37:21 PM: Copying Users on Witsend Using Instant Scan MacStateRem::msttDoBackup: VolDirGetMeta failed err -516 !Can't read state information, error -516 ( illegal request) 3/15/13 3:37:58 PM: Execution incomplete Completed: 26 files, 10.5 MB Performance: 209.9 MB/minute Duration: 00:00:24 (00:00:20 idle/loading/preparing) What is this, and how do I fix it, aside from going back to the 9.0 client? If it's relevant, I did the upgrade of the client via the console remotely. The 9.0 client had hung, and I did a quit of "retroclient" (stuck at 100% cpu) in the middle of the upgrade. I then re-did the upgrade. I have not yet re-booted the machine. I'll be doing that now.
  8. JamesOakley

    Instant Scan - how to get it to run

    Using Retrospect Professional 8, I am on Windows 7 (x64) and have one networked client (Windows 7, x86). If I run a backup script that includes volumes both on the local machine and on the client, the logs show "instant scan" as being used for the client volumes, but not for the local volumes. Starting a backup manually, and watching the file searches go through, would bear this out. Does anyone have any suggestions on how I might get Instant Scan working on my local installation?
  9. After upgrading to Retrospect 10.0.0, I found that previous backups and copy operations would not work on my QNAP NAS using AFP shares. Some folders could not be opened by Retrospect. I tracked this down to a problem with .DS_Store files being renamed. It seems they may cause problems with the new Instant Scan feature. This proved to be a difficult problem to solve, but I believe I found the cause. I detailed this problem and a solution in this post on my web site: http://www.folding-hyperspace.com/real-time-programming-tips/mac-ds_store-horrors.html I'm also going to bring this to the attention of Retrospect support.
×