- Oct. 09, 2011
Clearly, TM1 data directories should be backed up on a regular basis. For instance, an hourly, daily or weekly backup. These backup procedures could well be in the hands of IT. Odds are that these guys have backup facilities in place and TM1 administrators and consumers do not have to worry about possible data loss.
Data and logs
Any TM1 model contains the Data directory and the log files. Best practice teaches us to separate out the 2 parts in their own folder on the server. Next to that, it is not needed to backup the log folder if a Savedata procedure is done in TM1. This procedure will ask TM1 to write changes to the data in the respective cubes (.cub files in the Data directory). Changes in memory are then written to disk, the tm1s.log file will be renamed and an empty tm1s.log file is created.
We have several options to make backups. Widely used methods include batch processes to copy the data directory to another location, or a Turbo Integrator process to make a (zipped) copy of that folder. Fellow TM1 developer Ben Hill discussed the second approach only recently: read here on how to use 7-zip straight from TI.
Batch file code
Using batch files is another option. Below, you can find some custom code for a .bat file:
REM Wim Gielis REM http://www.wimgielis.comREM overwrite the contents of the backup folder REM with the current contents of the data dir D: XCOPY D:\TM1_PROD-DATA\*.* /S /E D:\TM1_PROD-DATA BACKUP\ /Y
D:\TM1_PROD-DATA\ stands for the TM1 data directory of 1 TM1 server, while D:\TM1_PROD-DATA BACKUP\ is the backup folder. This batch file could be scheduled to run each night using the Windows Task Scheduler. Decide whether to overwrite the previous backup, or create new ones in a different folder. Usually, the date and time are part of folder names too. Also often, previous backups are removed from the filesystem after a certain period of time. Several TM1 servers could be backed up like this (production, development, acceptance).
The code above, however, does not do a SaveData or does not stop the service for the TM1 model. The .cub files will not necessarily contain all data from the model in memory. A TI process (cfr. supra with Ben) could do a SaveDataAll() as part of the backup process. Here, we could do the Save data manually, although with nightly backups I won‘t be the person in the office at that time! A very small TI process with the SaveDataAll() command, scheduled to run some time before the batch file is executed, is a better alternative.
A third and more drastic way would be to stop and start the TM1 services for the backup. This shuts down the model completely and will update all files. As a side-product, all garbage memory consumed by TM1 is released again, which means a serious clean up in case the memory used approaches the limit of the server. As a consequence, TM1 users lose the benefit of calculated values stored in memory and consuming the model could be a little slower at start-up (depending on the size and complexity of the model, its calculations and other factors).
Backing up data to a different server could also be interesting but in general this is seldom done. The backup files are stored on the same physical server machine where the TM1 server(s) is/are running. But above script could be tweaked to have a copy destination on another server.
A second batch file
This second bach file will backup 2 TM1 servers, whereby the respective services are stopped during the backup. We could schedule this batch process for instance once every week.
REM Wim Gielis REM http://www.wimgielis.comREM Stop the services NET STOP "TM1 Admin Server" /Y NET STOP "TM1 Server / TM1_PROD" /Y NET STOP "TM1 Server / TM1_DEV" /Y REM overwrite the contents of the backup folder REM with the current contents of the data dir D: XCOPY D:\TM1_PROD-DATA\*.* /S /E D:\TM1_PROD-DATA BACKUP\ /Y XCOPY D:\TM1_DEV-DATA\*.* /S /E D:\TM1_DEV-DATA BACKUP\ /Y REM Start the services again NET START "TM1 Admin Server" NET START "TM1 Server / TM1_PROD" NET START "TM1 Server / TM1_DEV"
This batch file will:
- stop the TM1 Admin Server service (not really needed)
- stop the TM1 Server service(s) associated with the TM1 server(s) you want to backup
- execute a copy operation of the necessary files and folders
- start the TM1 Admin Server service
- start the TM1 Server service(s)
Should you still want to backup log files (for instance, when a TI process does not complete successfully, a detailed log file is available via the TM1 Message log), then you could use such a batch file. You should stop the TM1 service since certain files in the logging directory will be in use when a TM1 model is running - tm1s.log is an example of a locked file.
Needless to say, you can go much further than this. You could also zip directory/ies, send personalized emails for failure or success, … I will leave that up to the reader. By the way, Cognos Express comes with its own backup and recovery functions.