Re: [Fwd: Q's on backup to CD-R]
Actually, I haven't seen any data at all. My father told me that he
had seen that in a magazine article. I am quoting him.
The point of that was that CD-Rs were not a good storage medium for
programs.
For graphics or uncompressed music, they are fine. They're also fine
for
text files, where you can repair a broken bit with a spell-checker.
At the same time, though, 1 bit per 100k Bytes per year is still a darn
good rate when compared with data transmission. So if you have a
program that stores data on CD-Rs *recursively* -- that is, in two or
three different directories -- and with checksums on small parts of each
program (ie, the way IOMEGA's zip drives work) then there shouldn't be a
problem with that.
One interesting way of doing this would also be to mark things according
to data-critical level, and things that are highly critical (such as
programs or compressed data) get stored recursively, and near the center
of the disk. Other data that is not critical gets stored only one time,
and any recursion gets stuck at the edge of the disk.
But the best idea I can think of so far is the one that I said before.
Because for the most part, people's major storage isn't their own work
-- it is standard programs that are the same from system to system,
bitmap images of one form or another [including sound files]. Nor does
it change extensively from day to day. But backups are best made
regularly. So a good backup program should be able to store a minimum
of data, store it recursively, and retrieve any system or part of a
system or data, as of a certain date. And CD-R's are fine for that, as
long as it is done recursively.
I could well even see an automated system with automated CD changer that
used about 50 CDs a day (cost: $25/day) and could successfully back up a
whole university faculty's worth of computers. Daily, over the
network. In the background, when a person saves a file, that file and
its location gets stored in a "daily update" file on the local system.
If it gets deleted, it gets taken off the "daily update". Once a day --
at a different time for each computer -- when the computer is typically
not in use, it gets polled, and it uploads first the file map, and then
the files. The files are checked against preexisting versions, and then
stored, along with the directory structure (directories simply being
files in their own right.)
Since the recursion is crash-resistant, files could also be stored in
LZW-style trees, making the entire storage job much simpler, and more
compressed: programs written with the same libraries would have a
greater storage efficiency. However, the pointers and file references
would *not* be stored in LZW style, since that has to be the most
crash-resistant.
So now your typical Computing Services specialist simply loads a spindle
of CDs into the CD changer, sets it running, and then lets the system do
its job. And if something *does* crash, they can call up the computer
by its network ID, reinstall the entire system to a new hard drive, walk
up and exchange hard drives. Job done. Or write a few CD-Rs that
contain all of the relevant data, plus a small disk reformatting
routine, and then go up and reinstall the system of a few days back.
Then hit it with an antivirus check, if necessary.
P.S. I've now stepped off the listserver for the time being, so any
replies will have to be cc:d to me directly.
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: