Navigation:  The Server in depth > Server Extended Settings > Database Manager > Live Backups

Live Backups use what's called a Snapshot Transaction. A snapshot transaction represents the complete database in a consistent and stable state.  As long as all data modifications in your program always leave the database in a consistent state while no transaction is open, the backup will always be in a consistent state as well.

 

There is one possible problem.

 

During the lifetime of a snapshot transaction the server keeps copies of the original version of all blocks modified by other transactions. This isn't as bad as it sounds as only one copy is required the first time a specific block is changed... if the same block is changed multiple times during a snapshot transaction no additional copies are required. If new blocks are added to a table during a snapshot transaction no copies are required as there is no "original" block. There is also special code in place that makes sure that multiple active snapshot transactions share the same copy of the original block if possible.

 

Even with all these optimizations in place the amount of data required can become quite big under the following conditions:

 

These blocks will be stored in the "block cache" until MaxRAM has been reached and moved out to "temporary storage" as needed to keep total memory requirements below MaxRAM. If temporary storage has been completely filled the engine has no other choice than to ignore the MaxRAM setting and keep the blocks in memory. If this continues past the point where physical memory is available the OS will start swapping out these blocks to disk. This is the point where it gets ugly and the server will come to a crawl.

 

To prevent this problem you just have to make sure that temporary storage will be big enough to store all changes that can happen during the runtime of the backup. We also recommend scheduling backups at times where you expect the minimum modification to the data.