Filter
Top Products
33
If a write-in-place operation does occur, the D2D will create a new backup item that is not deduplicated, a
pointer to this new item is then created so that when the file is read the new write-in-place item will be accessed
instead of the original data within the backup file.
Backup size of data file with write-in-place item
If a backup application were to perform a large amount of write-in-place operations, there would be an impact
on backup performance.
Some backup applications provide the ability to perform “Synthetic Full” backups, these may produce a lot of
write-in-place operations or open a large number of files all at once, it is therefore recommended that Synthetic
Full backup techniques are not used, see Synthetic full backups on page 37 for more information.
Generally configuring larger backup file sizes will improve backup performance and deduplication ratio
because:
1. The overhead of the 24 MB dedupe region is reduced.
2. The backup application can stream data for longer without having to close and create new files.
3. There is a lower percentage overhead of control data within the file that the backup application uses to
manage its data files.
4. There is no penalty to using larger backup files as disk space is not usually pre-allocated by the backup
application.
5. Housekeeping may*not start until the large file is closed, lots of smaller files would result in housekeeping
running during the backup when the files are closed.
* See Housekeeping monitoring and control on page 71 for more details.
If possible the best practice is to configure a maximum file size that is larger than the complete backup will be
(allowing for some data growth over time), so that only one file is used for each backup. Some applications will
limit the maximum size to something smaller than that however, in which case, using the largest configurable size
is the best approach.
However in some specific cases using smaller backup files is of benefit. For example, in a replication
environment, using small files allows replication to start on each small file as soon as the backup application
closes it (assuming a replication blackout window is not in place). This allows either:
1. The replication of a single backup job to run along behind at the same time as the backup is running, or
2. If multiple replication jobs are running in parallel from a single source appliance or to a single target device,
the smaller file sizes prevent one backup job from locking out other backup jobs for the entire duration of the
replication. Instead, each backup replication job gets some replication time thus levelling out the time taken to
complete all replications rather than delaying one at the expense of another.