Initial commit
This commit is contained in:
34
customcd/files/root/rescuebru/rescuebru-help/bucomp.txt
Normal file
34
customcd/files/root/rescuebru/rescuebru-help/bucomp.txt
Normal file
@@ -0,0 +1,34 @@
|
||||
|
||||
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.
|
||||
Reference in New Issue
Block a user