Redo log

Abstract: One embodiment is a method for providing incremental backups for a source computing machine, the method including: (a) creating a first backup snapshot including a virtual machine (VM) snapshot of an initial copy of a source computing machine volume, wherein said VM snapshot includes a timestamp and a first redo log file; (b) reconfiguring and customizing said first backup snapshot to create a first bootable VM, writing changes associated with said reconfiguring and customizing into said first redo log file, then creating a first bootable snapshot including a VM snapshot of said first bootable VM, wherein said VM snapshot of said first bootable VM includes a timestamp for said first bootable VM and a redo log file; (c) performing an incremental update of said first backup snapshot or a subsequent backup snapshot, then creating a subsequent backup snapshot including a VM snapshot of said incremental update, wherein said VM snapshot of said incremental update includes a timestamp for said incremental update and a redo log file; and (d) reconfiguring and customizing said subsequent backup snapshot to create a subsequent bootable VM, then creating a subsequent bootable snapshot including a VM snapshot of said subsequent bootable VM, wherein said VM snapshot of said subsequent bootable VM includes a timestamp for said subsequent bootable VM and a redo log file.

Abstract: A method of automatically synchronizing a database with a backup database. The method automatically detects whether the backup database has fallen out of sync with the primary database which it mirrors. In response, a resynchronization process is automatically initiated in which the starting point for reading a redo log of the primary database is automatically determined and in which the backup database is automatically synchronized with the primary dataset.

Abstract: A database rollback processor allows rollback, or rewind, of the data and metadata to a point at which a failover or other metadata change occurred, therefore “rewinding” the metadata to a previous consistent point. The rollback processor identifies transaction entries in a redo log resulting in changes to the metadata. The changes are identified backward to a target recovery time. Transactions affecting the metadata are stored in a stack. The transactions are then backed out of the metadata according to the stack to restore the metadata to the state at the target recovery time. Data changes from the redo log may then be applied to the corresponding metadata as it existed at the target recovery time. Since the target recovery time is not bound by the timing of the snapshots, but rather may be at an arbitrary point chosen as the target recovery time, a failover, replication or recovery operation need not rely on the snapshot time.

Abstract: Byte addressable persistent memory eliminates the need for serialization and deserialization of data, to and from persistent storage, allowing applications to interact with it through common store and load instructions. In the event of a process or system failure, applications rely on persistent techniques to provide consistent storage of data in non-volatile memory (NVM). For most of these techniques, consistency is ensured through logging of updates, with consequent intensive cache line flushing and persistent fences necessary to guarantee correctness. Undo log based approaches require store interposition and persistence fences before each in-place modification. Redo log based techniques can execute transactions using just two persistence fences, although they require store and load interposition which may incur a performance penalty for large transactions. So far, these techniques have been difficult to integrate with known memory allocators, requiring allocators or garbage collectors specifically designed for NVM. We present Romulus, a user-level library persistent transactional memory (PTM) which provides durable transactions through the usage of twin copies of the data. A transaction in Romulus requires at most four persistence fences, regardless of the transaction size. Romulus uses only store interposition. Any sequential implementation of a memory allocator can be adapted to work with Romulus. Thanks to its lightweight design and low synchronization overhead, Romulus achieves twice the throughput of current state of the art PTMs in update-only workloads, and more than one order of magnitude in read-mostly scenarios.