A recent survey conducted by Vanson Bourne on one thousand UK companies
suggests businesses are on average backing up to tape once a month, with one
rather alarming statistic from the same survey showing 10 percent were only
backing up to tape once per year.
Although Cloud backup solutions are becoming more common, still the
majority of companies will do their backups in-house. Sometimes they will
have dedicated IT staff to run them, but usually it's done in-house because
they have always done it like that, and they have confidence in their own
security and safekeeping of data. But given this fact that IT personal are
perhaps creatures of habit, and wouldn't risk a cloud based back-up solution
- due to security and/or data integrity - it then seems a little odd that
backups are done as infrequently as the survey reveals or even that they are
only done once per year by some companies.
The likely reason for this infrequency is due to the time factor
involved. Many companies would run their backups on Friday evenings, in the
hope for it to be completed by Monday business start. But with such large
data pools, these backups might not complete in time, and are therefore
often postponed for larger time frame windows.
Longer Backup times
The I/O bottleneck caused by disk fragmentation is a primary cause for
latent backup times. As data backup involves file access, fragmentation of
data files is anticipated to have pronounced impact on the length of time a
backup procedure may take. An entire data set needs to be read, and then
copied elsewhere. This data set could be spread across one volume or many.
If a high number of additional I/Os are required to read files before they
are transferred, backup speed is heavily impacted. At best, the result is a
backup that is greatly slowed down, and at worst it is a failed backup.
Additional I/Os are needed when files are split into multiple pieces -
fragments. It is not at all uncommon to see a file fragmented into thousands
or even tens of thousands of fragments. The impact on backups of files in
such a state is considerable.
Snapshots/CDP
It is common now especially with SANs to use Snapshots and CDP, but any
block level changes would mean an increase in the replication traffic or
increase in the Snapshot size - and larger snapshots would take longer to
backup. Having said this we still need to defragment as fragmented volumes
take considerable time to backup. In such situations, actually preventing
fragmentation before it can occur is the ideal solution.
Prevention better than Cure
So, what is the best way to handle the problem of fragmentation at the
NTFS level? Well, prevention is better than cure. It is far better to have a
way to leverage the Windows Write Driver so that it writes a file more
intelligently to a large enough area of contiguous free space to write the
file in one chunk, rather than split it up into fragments. For example, if
Windows was to write a file into 20 fragments, then the following would
happen: The first fragment of the file would be written to the NTFS volume,
this would then travel down the storage stack to the SAN controller, which
in turn would write it out to the physical disks in its array. Then the next
fragment would cascade down the storage stack, and the next, and so on,
until all 20 fragments had travelled down the storage stack to the SAN.
Conversely, if the Windows Write Driver was to write a file in one
contiguous (non-fragmented) chunk, only one I/O would travel down the
storage stack. This not only provides a performance benefit to the Windows
machine but can also help reduce I/O queues at the SAN level, and have the
physical disks in the SAN array work less hard, which in turn will lengthen
their life. Obviously by preventing these excess I/Os you will improve the
backup times as well.
For a Business Solution Software which can help reduce back-up times, as
well as increase overall system performance, download a free trialware by
clicking here [http://ow.ly/7vbH9 ].