During any restore procedure it is critical that no application activity occurs in the databases being restored until you are completely finished with the backup restore and journal restore, and you have completed any desired application-level validation. If you have, in your application or operating environment, a mechanism to ensure that no user activity can occur when Caché is started you can use that mechanism; for example, if your application is entirely web-based, shutting down the web servers may be sufficient to ensure that only administrators involved in the restore procedure have access to the system.(https://cedocs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=GCDI...)

Can setting switch meet the demand?

I am doing work related to backup and restore, to avoid unexpected problems with other user operations during restore, so I started in emergency mode

still not work

Thank for your reply.  When I used the method of  "do ^JRNRESTO" ,  the filter worked fine and  I got the data as I expected.  So my problem is that the following code is not working properly, or I missed something.

s RestOref=##class(Journal.Restore).%New()
s RestOref.FirstFile="20190717.007"
s RestOref.LastFile="20190717.007"
s RestOref.JournalLog="journal.log"
s RestOref.Filter="^ZJRNFILT"
s Status=RestOref.Run()

when I use "do ^JRNRESTO" it works?

This utility uses the contents of journal files
to bring globals up to date from a backup.

Restore the Journal? Yes => Yes
Use current journal filter (ZJRNFILT)?   enter Yes or No, please
Use current journal filter (ZJRNFILT)? yes
Use journal marker filter (MARKER^ZJRNFILT)?   enter Yes or No, please
Use journal marker filter (MARKER^ZJRNFILT)? no
Apply filter to every selected file? Yes => Yes
Process all journaled globals in all directories? yes
Are journal files created by this Cache instance and located in their original
paths? (Uses journal.log to locate journals)? yes
Specify range of files to process

Enter ? for a list of journal files to select the first and last files from
First file to process:  

Entry must be from the list, please re-enter

First file to process:  

Entry must be from the list, please re-enter

First file to process:  

Entry must be from the list, please re-enter

First file to process:  1 /home/lw/mgr/journal/20190718.008
Final file to process:  /home/lw/mgr/journal/20190719.009 => 
Prompt for name of the next file to process? No => No

The following actions will be performed if you answer YES below:

* Listing journal files in the order they will be processed
* Checking for any missing journal file on the list ("a broken chain")

The basic assumption is that the files to be processed are all
currently accessible. If that is not the case, e.g., if you plan to
load journal files from tapes on demand, you should answer NO below.
Check for missing journal files? Yes => Yes

Journal files in the order they will be processed:
1. /home/lw/mgr/journal/20190718.008
2. /home/lw/mgr/journal/20190718.009
3. /home/lw/mgr/journal/20190718.010
4. /home/lw/mgr/journal/20190719.001
5. /home/lw/mgr/journal/20190719.002
6. /home/lw/mgr/journal/20190719.003
7. /home/lw/mgr/journal/20190719.004
8. /home/lw/mgr/journal/20190719.005
9. /home/lw/mgr/journal/20190719.006
10. /home/lw/mgr/journal/20190719.007
11. /home/lw/mgr/journal/20190719.008
12. /home/lw/mgr/journal/20190719.009

While the actual journal restore will detect a journal integrity problem
when running into it, you have the option to check the integrity now
before performing the journal restore. The integrity checker works by
scanning journal files, which may take a while depending on file sizes.
Check journal integrity? No => No
The journal restore includes the current journal file.
You cannot do that unless you stop journaling or switch
     journaling to another file.
Do you want to switch journaling? Yes => Yes
Journaling switched to /home/lw/mgr/journal/20190719.010

You may disable journaling of updates for faster restore for all
databases other than mirrored databases. You may not want to do this
if a database to restore is being shadowed as the shadow will not
receive the updates.
Do you want to disable journaling the updates? Yes => Yes
Updates will NOT be journaled
Before we job off restore daemons, you may tailor the behavior of a
restore daemon in certain events by choosing from the options below:

     DEFAULT:    Continue despite database-related problems (e.g., a target 
     database is not journaled, cannot be mounted, etc.), skipping affected 
     updates 

     ALTERNATE:  Abort if an update would have to be skipped due to a 
     database-related problem (e.g., a target database is not journaled, 
     cannot be mounted, etc.) 

     DEFAULT:    Abort if an update would have to be skipped due to a 
     journal-related problem (e.g., journal corruption, some cases of missing 
     journal files, etc.) 

     ALTERNATE:  Continue despite journal-related problems (e.g., journal 
     corruption, some missing journal files, etc.), skipping affected updates 

Would you like to change the default actions? No => No

Start the restore? Yes => Yes

***WARNING: Not restoring /home/lw/mgr/ because the database is not journaled

***WARNING: Not restoring /home/lw/mgr/cachelib/ because the database is not journaled

***WARNING: Not restoring /home/lw/mgr/cachetemp/ because the database is not journaled

***WARNING: Not restoring /home/lw/mgr/cache/ because the database is not journaled

***WARNING: Not restoring /home/lw/mgr/docbook/ because the database is not journaled

***WARNING: Not restoring /home/lw/mgr/samples/ because the database is not journaled

/home/lw/mgr/journal/20190718.008
100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190718.009
  92.15%  94.17%  96.04%  98.06%  99.93%100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190718.010
  62.62%  64.67%  66.53%  68.58%  90.91%100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.001
  78.55%  84.13%  88.61%  99.42%100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.002
  73.58%  79.37%  91.91%100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.003
100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.004
100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.005
100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.006
100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.007
100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.008
100.00%
***Journal file finished at 11:47:30

/home/lw/mgr/journal/20190719.009
100.00%
***Journal file finished at 11:47:30

[journal operation completed]
Do you want to rename your journal filter? yes
Journal filter ZJRNFILT renamed to XJRNFILT
 

Consider the following when using ^ZJRNFILT:

• If the startup routine (^STU) calls ^JRNRESTO, it does not call the filter routine under any circumstances.

how can I know whether the startup routine calls ^JRNRESTO or not?

I change to 

ZJRNFILT(jid,dir,glo,type,restmode,addr,time) /*Filter*/
   Set restmode=1 /*Return 1 for restore*/
   If glo["ABC",type="K" Set restmode=0 /*except if a kill on ^ABC*/
   Quit
   ;

it still not work,  and has  `kill command` in journal  :

"["means contain, so there is no diffence between "ABC" and "^ABC" here??