Recovering an accidentally deleted global

InterSystems FAQ rubric

In this article, we will introduce how to deal with the situation: "I accidentally deleted a global!"

Backup files and journals are used to recover specific globals that have been accidentally deleted. Restoration is performed by specifying conditions and restoring journal records using the ^ZJRNFILT utility. In this way, you can apply a point-in-time backup of the database up to and including deleting a specific global for journal records that contain deletions. For more information on the ^ZJRNFILT utility, please refer to the document below:

Filter Journal Records Using ^ZJRNFILT [IRIS]
Filter Journal Records Using ^ZJRNFILT

【Example】

  - A backup as of 2020/10/14 exists (assuming that the backup was executed at 2020/10/15 0:30)
     Journal: 1 day of 2020/10/15 exists (2020/10/15) After the backup on 10/14)
  ・Target global: ^TEST1

The image is below.

Global ^TEST1 will be populated from 10/14.
The global ^TEST1 was accidentally deleted with a KILL statement at 15:30 on October 15th.
At this stage, we want to restore the global ^TEST1 just before the KILL statement was issued.
 In the execution example, ^TEST1(1) to ^TEST1(100) are restored using the global journal created by the command below.

[Recovery procedure]

1. Backup/restore or copy (mount) backed up database files (CACHE.DAT/IRIS.DAT) to another system
2. Copy journals after backup acquisition to another system
3. Identify killed journal records for the last journal file
   
   • Note 1: Viewing the journal record in the Management portal ( Management portal > [System Operations] > [Journals] > click the [Browse] link for the target file  ) (In the example shown, the journal record for KILL  9060180 can be seen)  
   • Note 2: You can also check journal records using the system routine SELECT^JRNDUMP .
4. Restoring journal files in order, only globals to be restored are OK.
5. Use ZJRNFILT only for last journal file
6. Export recovered global, copy & import to original system

Below is an example of the 5th ZJRNFILT routine (created with the routine name: ZJRNFILT in the %SYS namespace).

ZJRNFILT (pid,dir,glo,type,restmode,addr,time) 
set  restmode =1// If TEST1 is included in the global variable name // and the journal record is 9060180 or later, set restmode=0 (=do not restore) if  ( glo  [ "TEST1" ) & ( addr >=9060180) { 
   set  restmode =0
} 
quit

An example of restoring the last journal file using ZJRNFILT is shown below (inputs are in bold blue letters).

1. %SYS>do ^JRNRESTO
2.  
3. This utility uses the contents of journal files
4. to bring globals up to date from a backup.
5.  
6. Restore the Journal? Yes => Yes
7. Use current journal filter (ZJRNFILT)? yes
8. Use journal marker filter (MARKER^ZJRNFILT)? no
9. Apply filter to every selected file? Yes => yes
10. Process all journaled globals in all directories? no
11. Are journal files imported from a different operating system? No => no
12.  
13. Directory to restore [? for help]: c:\intersystems\hscv\mgr\user\   c:\intersystems\hscv\mgr\user\
14. Redirect to Directory: c:\intersystems\hscv\mgr\user\
15.  => c:\intersystems\hscv\mgr\user\--> c:\intersystems\hscv\mgr\user\
16. Process all globals in c:\intersystems\hscv\mgr\user\? No => no
17.  
18. Global ^TEST1
19. Global ^
20.  
21. Directory to restore [? for help]:
22.  
23. Processing globals from the following datasets:
24.  1. c:\intersystems\hscv\mgr\user\   Selected Globals:
25.           ^TEST1
26.  
27. Specifications correct? Yes => yes
28. Are journal files created by this IRIS instance and located in their original
29. paths? (Uses journal.log to locate journals)? no
30. If you have a copy of the journal history log file from the Cache or IRIS
31. instance where the journal files were created, enter its full path below;
32. otherwise, press ENTER and continue.
33. Journal history log:
34. Specify range of files to process (names in YYYYMMDD.NNN format)
35.  
36. from:     <20201012.002> [?] => 20201015.001
37.  
38. through:  <20201015.001> [?] =>
39.  
40.  
41. Provide or confirm the following configuration settings:
42.  
43. Journal File Prefix: [?] =>
44.  
45. Files to dejournal will be looked for in:
46.      c:\intersystems\hscv\mgr\journal\
47. in addition to any directories you are going to specify below, UNLESS
48. you enter a minus sign ('-' without quotes) at the prompt below,
49. in which case ONLY directories given subsequently will be searched
50.  
51. Directory to search: <return when done>
52. Here is a list of directories in the order they will be searched for files:
53.      c:\intersystems\hscv\mgr\journal\
54. Prompt for name of the next file to process? No => no
55.  
56. The following actions will be performed if you answer YES below:
57.  
58. * Listing journal files in the order they will be processed
59. * Checking for any missing journal file on the list ("a broken chain")
60.  
61. The basic assumption is that the files to be processed are all
62. currently accessible. If that is not the case, e.g., if you plan to
63. load journal files from tapes on demand, you should answer NO below.
64. Check for missing journal files? Yes => no
65.  
66. You may disable journaling of updates for faster restore for all
67. databases other than mirrored databases. You may not want to do this
68. if a database to restore is being shadowed as the shadow will not
69. receive the updates.
70. Do you want to disable journaling the updates? Yes => yes
71. Updates will NOT be journaled
72. Before we job off restore daemons, you may tailor the behavior of a
73. restore daemon in certain events by choosing from the options below:
74.  
75.      DEFAULT:    Continue despite database-related problems (e.g., a target
76.      database is not journaled, cannot be mounted, etc.), skipping affected
77.      updates
78.  
79.      ALTERNATE:  Abort if an update would have to be skipped due to a
80.      database-related problem (e.g., a target database is not journaled,
81.      cannot be mounted, etc.)
82.  
83.      DEFAULT:    Abort if an update would have to be skipped due to a
84.      journal-related problem (e.g., journal corruption, some cases of missing
85.      journal files, etc.)
86.  
87.      ALTERNATE:  Continue despite journal-related problems (e.g., journal
88.      corruption, some missing journal files, etc.), skipping affected updates
89.  
90. Would you like to change the default actions? No => no
91.  
92.  
93. Start the restore? Yes => yes
94.  
95.  
96.  
97. c:\intersystems\hscv\mgr\journal\20201015.001
98. 100.00%
99. ***Journal file finished at 15:43:05
100.  
101. [journal operation completed]
102. Do you want to delete your journal filter? yes
103. Journal filter ZJRNFILT deleted
104.  
105. %SYS>

When restoring a global by journal restore, **for safety** we recommend replicating the database and journal in an environment other than the production environment. Therefore, export the restored global and transfer (copy) it to the production environment.

For details on the messages displayed during journal restore, please also refer to the documentation.