On Wed, 22 Aug 2001, Jiang Wei wrote:
> Marc a �galement propos� un cours de Unix (linux) backup pour GULL, on
> attend tous avec impatient ce cours ....
:)
J'ai d�j� �crit la mati�re, mais pas le contenu. Etonnamment je l'ai �crit
en anglais, je pensais faire quand m�me le cours en fran�ais ...
$Id: NOTES,v 1.5 2001/08/05 14:32:38 schaefer Exp $
NOTES
BUGS
TODO
- Also see email GULL, and ESNIG course
- Plan:
What are the expectations in a backup solution ?
- Ability to restore (trivial?)
-> is _everything_ you need backed up ? Completeness,
exclude lists ?
Horror stories: Novell server not backuped up at all
because number of license problem.
-> do you have small enough backup interval ?
Ie, how much are you ready to loose with certainty ?
-> do you have enough backup _history_ ? multiple ways
to restore the data ?
Where is this file that was deleted/infected/corrupted
2 months ago ?
-> is the quality of the data storage correct ?
-> quality of tapes
-> quality of drive
-> cleaning
-> volume auditing
This is how you can evaluate:
-> data verification: on-site, off-site, regular.
-> error counters
-> verify this ability to restore regularly, if possible
automatically.
-> off-site is important, but round-robin verify!
- Correctness: databases or file/set of files that change cannot
simply be backuped. Some tools have bugs (dump,
cpio, tar).
Examples: - GNU tar --verify doesn't work with --sparse
- some versions of cpio have bugs
- some tar/cpio implementation are buggy when
you change things under them
(http://reality.sgi.com/zwicky_neu/testdump.doc.html)
- dump is basically moot with Linux unless
you remount ro.
Linus Torvalds, in linux-kernel:
http://search.alphanet.ch/cgi-bin/search.cgi?max_results=10&type=long&[EMAIL PROTECTED]&domain=ml-linux-kernel
said:
Note that dump simply won't work reliably at all even in 2.4.x: the buffer
cache and the page cache (where all the actual data is) are not
coherent. This is only going to get even worse in 2.5.x, when the
directories are moved into the page cache as well.
[ ... ]
Dump was a stupid program in the first place. Leave it behind.
- coherency: would require snapshots *and*
user implementation/backup API.
- dump script of PostgreSQL and Oracle.
- Compatibility (cross-plateform, cross-vendor) and durability
of the chosen standards (hardware, but also software formats).
Horror story: Novell backup cannot be restaured unless you
still have Novell 3.01 installation diskettes,
keys, and compatible hardware.
Examples: Arkeia, also commercial, has an open data format,
and an open-source restore utility.
- Security
Meta (control) authentification (when to start, etc)
Should data be encrypted on transit, on tape, on client ?
Example: ISP backups its customers (hosted *machines*).
Customers want to be the only one able to
decode the data, while the server can still
verify that the whole data hasn't been corrupted
(md5sum) with auditing.
Key escrow ?
Technologies ? (SSL/ssh/whatever ?)
- Push or pull ? (server or client/laptop)
- Efficiency: backup speed, efficient use of tape, ease of
configuration, and restauration, statistics,
configurability.
Sometimes opposes to the ability to restore: one tape per
day might be wasteful, but is safer.
Multiple copies are more costly.
Disk is cheap. RAID1 is no backup. An offsite tape is
better than an onsite disk.
- Simplicity ?
Configuration simplicity.
From scratch restauring.
- Flexibility ?
Strange schemes where control/index/master server must be
at the end of a slow line, and local tape drives used.
- Interfaces: end-user restoring, backup policies ?
Common strategies
Hano�
Amanda smoothing
Always full.
Backup plan / disaster recovery plan
It's not just about tapes and tape drives!
Strongly linked with the ability to restore.
A disaster recovery plan is the ability to recover your system
fully when everything has burnt: it means hardware, OS software,
applications and data. It also means the ability to read the
medium on a possibly new hardware.
Hardware
Implementation example with Amanda
error_counters
choice of DDS-4
From 4 GB (daily) to 20 GB (archives)
gzip + amverify, compression of on tape -> volume audit
amcompare
restauration example
disaster recovery floppy
References
- UNIX backup & recovery, W. Curtis Preston, ISBN 1-56592-642-0
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
