Versions of Investor/RT up to and including present day 13.2.8 use a 32-bit database management system to store all historical data and user preferences and setups. The RT 13 database is housed in the InvestorRT\data_f directory; it consists of a collection of ~60 files. The Backup Database mechanism for the RT 13 database is essentially a daily "mirror copy" made to the backup_f directory. The ~60 files are simply duplicated when a backup is made. The Restore Database function takes the most recent backup_f files and replaces the files in the data_f.

Several years ago, the restore point feature was added, in RT 10 as I recall. The restore point creation process operates alongside the daily "mirror" backup mechanism. A restore point is a highly compressed file containing the database files. They can be created with historical data included or excluded. Restore points that exclude historical data are quickly produced, taking only a second or two typically. Restore points are created every day or two; think of them as snapshots of your database at some specific date/time. In the event of an RT 13 database issue, the first remedy is to Restore Database to the mirrored copy. Restore points give you additional flexibility to restore back to some earlier date in the past. Restore point files are kept in the InvestorRT\archives directory for the most recent 30 days or so.

When Investor/RT 14 was introduced, the role of restore points changed. RT 14 utilizes a more modern 64-bit compatible database system. The database files are kept in the InvestorRT\db directory. The phyiscal database can be used by RT 14, a 32-bit appication, or by the upcoming RT 15 64-bit version of the Investor/RT platform (available for beta testing now). RT 14 and higher no longer use the mirror-copy method of keeping a daily backup. The Backup Database functionality instead produces a restore point named BackupDatabase.dba, a single file that contains a snapshot of the files in the \db directory including the historical database files. The Restore Database function in RT 14 and higher is internally a revert to restore point of the current BackupDatabase.dba. The restore point mechanism in RT 14 and higher continues to operate in parallel with the daily backup restore point, creating a snapshot of your setups every day or so. Like RT 13 and earlier, you have the flexibility to revert back to the most recent BackupDatabase.dba or any other restore point in your \archives directory.

There are several configuration variables defined in File > Preferences > Configuration that enable you to customize how restore points are made, with or without historical data, how frequently to make them, how many to keep around, how long to keep them. The daily creation of BackupDatabase.dba, for example, includes all historical data by default. If you prefer, you can set the variable AutoBackupIncludeHistData to false. The daily BackupDatabase.dba will thereafter be much smaller and will be produced much faster. In the unusal event that you need to restore a backup that has no historical data, Investor/RT will request fresh historical data when it connects to your data sources.

In conclusion, for RT 14 and higher, the term backup database is synomymous with create restore point, and restore database is synonymous with revert to restore point. The restore point used for backup and restore has the special name BackupDatabase.dba. Other restore point files (.dba files) that are created manually or automatically by RT have names that begin with RestorePt followed by digits (date_time stamp). RestorePt... file names are suffixed with NoHist if the file contains no historical data.