1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<!--Converted with LaTeX2HTML 96.1-h (September 30, 1996) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds -->
<HTML>
<HEAD>
<TITLE>Compressed backups</TITLE>
<META NAME="description" CONTENT="Compressed backups">
<META NAME="keywords" CONTENT="sag">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<LINK REL=STYLESHEET HREF="sag.css">
</HEAD>
<BODY LANG="EN" >
<A NAME="tex2html1635" HREF="node106.html"><IMG WIDTH=37 HEIGHT=24 ALIGN=BOTTOM ALT="next" SRC="./next_motif.gif"></A> <A NAME="tex2html1633" HREF="node96.html"><IMG WIDTH=26 HEIGHT=24 ALIGN=BOTTOM ALT="up" SRC="./up_motif.gif"></A> <A NAME="tex2html1629" HREF="node104.html"><IMG WIDTH=63 HEIGHT=24 ALIGN=BOTTOM ALT="previous" SRC="./previous_motif.gif"></A> <A NAME="tex2html1637" HREF="node1.html"><IMG WIDTH=65 HEIGHT=24 ALIGN=BOTTOM ALT="contents" SRC="./contents_motif.gif"></A> <A NAME="tex2html1638" HREF="node114.html"><IMG WIDTH=43 HEIGHT=24 ALIGN=BOTTOM ALT="index" SRC="./index_motif.gif"></A> <BR>
<B> Next:</B> <A NAME="tex2html1636" HREF="node106.html">Keeping Time</A>
<B>Up:</B> <A NAME="tex2html1634" HREF="node96.html">Backups</A>
<B> Previous:</B> <A NAME="tex2html1630" HREF="node104.html">What to back up</A>
<BR> <P>
<H1><A NAME="SECTION001170000000000000000">Compressed backups</A></H1>
<P>
Backups take a lot of space, which can cost quite a lot of money.
To reduce the space needed, the backups can be compressed. There
are several ways of doing this. Some programs have support for
for compression built in; for example, the <tt>-gzip</tt> (<tt>-z</tt>)
option for GNU <tt>tar</tt><A NAME="3099"> </A> pipes the whole backup through the
<tt>gzip</tt><A NAME="3101"> </A> compression program, before writing it to the backup
medium.
<P>
Unfortunately, compressed backups can cause trouble. Due to the
nature of how compression works, if a single bit is
wrong, all the rest of the compressed data will be unusable. Some
backup programs have some built in error correction, but no method
can handle a large number of errors. This means that if the
backup is compressed the way GNU <tt>tar</tt><A NAME="3103"> </A> does it, with the
whole output compressed as a unit, a single error makes all the
rest of the backup lost. Backups must be reliable, and this
method of compression is not a good idea.
<P>
An alternative way is to compress each file separately. This still
means that the one file is lost, but all other files are unharmed.
The lost file would have been corrupted anyway, so this situation
is not much worse than not using compression at all. The <tt>afio</tt><A NAME="3105"> </A>
program (a variant of <tt>cpio</tt><A NAME="3107"> </A>) can do this.
<P>
Compression takes some time, which may make the backup program
unable to write data fast enough for a tape drive.<A NAME="tex2html52" HREF="footnode.html#3016"><IMG ALIGN=BOTTOM ALT="gif" SRC="./foot_motif.gif"></A> This can be
avoided by buffering the output (either internally, if the backup
program if smart enough, or by using another program), but even that
might not work well enough. This should only be a problem on slow
computers.
<P>
<BR> <HR>
<P><ADDRESS>
<I>Lars Wirzenius <BR>
Sat Nov 15 02:32:11 EET 1997</I>
</ADDRESS>
</BODY>
</HTML>
|
