Both local and network backups create a self-contained and self-consistent image of a database by copying necessary files to the user-specified backup directory.
Every backup makes a checkpoint as its first action. This guarantees that the possible restore starts with as fresh backup as possible. This way, the slower roll-forward portion of the restore is minimized. The following files are then copied by default to the specified backup directory:
▪Database files containing the checkpointed database itself
▪Log files including changes made by those transactions that are active when the backup takes place
▪solmsg.out database message file (provided for convenience in diagnosing problems — the message file is not required during a restore), and
▪solid.ini configuration file is also copied by default because after a disk crash the original might be destroyed (the configuration file is not required during a restore).
The solid.lic license file is not automatically copied.
Note The name of the database files and their maximum size are specified in the FileSpec[1...N] parameters in the [IndexFile] section of the solid.ini configuration file. The name and location of log files is specified in the [Logging] section of the configuration file.
The log files are typically deleted from the source server after they have been copied to the backup directory since they have become useless. The deletion is part of the default backup procedure and it is referred to as full backup.
It is, however, possible to retain all the log files produced over time by the update transactions in the database server directory. Keeping all the log files is space‑consuming but allows, for instance, bringing the database up-to-date by re‑executing all the updates by using the log files only. This backup type is called copy backup.
Note If you want to use copy backups, that is, retain the full log file history, you must also ensure that the log files are not deleted at the end of checkpoint. To prevent deletion of log files, set the General.CheckpointDeleteLog parameter to no.
Local backup
In local backup the database and the log files are copied from the database directory to user specified backup directory accessible from within the same machine.
If the backup directory already includes files with same names, they are overwritten. If the specified backup directory does not exist, the backup fails and the call returns an error.
Note Ensure that backup and database directories are both on different physical device and in different file system than database files. If one disk drive is damaged, you lose either your database files or backup files but not both. Similarly, if one file system fails, either the backup or the database files survives.
Network backup
Network backup (netbackup) is a facility for storing the whole database at some remote location. Netbackups are performed using a solidDB® Netbackup Server whose function is to receive backups over the network. One Netbackup Server can serve multiple simultaneous backup source servers.
Similarly to local backup, the files are written into a user specified directory in the Netbackup Server. If the target netbackup directory includes files with the same names, they are overwritten. Unlike the local backup, if the specified remote directory does not exist, it is created automatically.
solidDB® Netbackup Server requires the administrator privileges from the caller of netbackup. Less privileged users can perform netbackup by using stored procedures that are created by an administrator. In that case, the user must be granted the right to execute the procedure.
Netbackup can be performed between different server versions if they are netbackup compatible. By principle, a newer version of the Netbackup Server can serve older versions of source servers. In other cases, the protocol version is checked and an incompatibility error is returned at the request for a netbackup. By principle, a newer version of the Netbackup Server can serve as a target server for an older version of source server.