35 lines
1.5 KiB
Plaintext
35 lines
1.5 KiB
Plaintext
|
|
This determines the level of compression used when doing a backup. The
|
|
following options are available:
|
|
|
|
low
|
|
|
|
Uses either no compression (for partimage and dd) or the lzo
|
|
compression algorithm (for fsarchiver). The advantage is that it's
|
|
very fast on the client side. The disadvantage is that the size of
|
|
the backup will be large; in most cases as large as the original
|
|
data. Using this setting really only makes sense if you have vast
|
|
amounts of storage space for your backups and a very fast network,
|
|
or if you know that your data is pretty much uncompressible, such as
|
|
a compressed database. Note that even though low compression is fast
|
|
on the client side, you may still run into speed limitations of the
|
|
storage subsystem on the server side, or of the network.
|
|
|
|
normal
|
|
|
|
Uses the gzip compression algorithm to give the best compromise
|
|
between speed and backup size. This is the default compression level.
|
|
|
|
high
|
|
|
|
Uses the bzip2 compression algorithm (for partimage and dd) or the
|
|
lzma compression algorithm (for fsarchiver). This results in a very
|
|
good compression ratio requiring less space to store the backup.
|
|
However, this comes at the price of high CPU and memory usage on the
|
|
client side. A backup done with high compression will probably take
|
|
a long, long time to accomplish. Additionally, if there is
|
|
insufficient memory available on the client, the compression may
|
|
fail altogether, resulting in the backup being stored uncompressed.
|
|
If you want to use high compression, testing is advised before
|
|
deciding to use it for real.
|