Let’s first see what is the content of the cache: metadata informations are obviously way smaller than the data they refer to, but still they consume some amount of memory.

To improve performances, the target datamover loads dynamically these metadata informations into memory. Before Veeam Backup & Replication v8 Update 2, the cache was used to accelerate writes, while in Update 2 it’s now also used to accelerate read operations but there are also differences in the way the cache is populated and used. This is extremely important especially in a scale-out design, when multiple proxies are writing data into the same backup file: blocks coming from different proxies might be duplicated, so the right point in the chain to compare them is the target datamover itself. When a new block needs to be written into the repository, for example during an incremental backup, the Veeam datamover component running in the repository (also referred as the target datamover) has to read these metadata, compare the hashes of the stored blocks with the incoming blocks arriving from a proxy, and decide if this block has to be stored because it’s new, or it just needs to update the metadata informations when the block is already stored from a previous write operation. As in any deduplicated storage, in order to keep track of stored blocks, there are metadata informations stored along the file itself (Remember, in Veeam metadata are compared inside the same file, not as a global deduplication system). The amount of memory consumed by the queue is simple to be calculated: it uses up to 2 GB of memory per active job.īut this is not the only memory consumed by the repository: Veeam backup files contains deduplicated informations of the saved blocks. This allows to reduce to a minimum random IO impacting the backup files, while trying to serialize as much as possible the writes operations. This queue collects all blocks coming from proxies, caches them in memory and after some optimizazions it is flushed to disk. But given the fact memory is multiple times faster than disk, this is a good tradeoff.Īt a first level, a repository uses memory to store incoming blocks. Obviously, there’s always a tradeoff between disk IO and memory IO, so any saved IO on the storage has to be compensated by some additional IO on memory. In order to speed IO operations on disk, a Repository leverages multiple technologies involving memory. What Veeam repository stores in memoryĪ Veeam Repository is responsible for the collection of saved blocks coming from proxies and their storage on a disk target, local or remote.

Here are some informations for its proper configuration. One of the most important parameter when sizing a repository is its expected memory consumption. Veeam repositories, both Windows and Linux based, are running a software component responsible for receiving and storing data as they are processed by proxies. 0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email - 0 Flares ×

Calculator veeam