Announcing release 0.1 of "harchive", a program for backing up and
restoring data. I've included a brief feature list below. The code
is available in darcs at:
http://www.davidb.org/darcs/harchive/
The connection isn't all that fast, so if it gets too busy, I'll move
it somewhere else.
This software is in a very early stage, but is at the point where
others may be interested in looking at it. It does demonstrate that
Haskell (at least GHC) is indeed useful for this kind of low-level
seeming task.
Thanks,
David Brown
Harchive version 0.1.
- Implemented, with support for the following.
- Client/server model. The backup is stored in a file pool with
the hpool program. The hfile program can access this pool over
tcp (no authentication or encryption, so be careful).
- Stores data from multiple backups and multiple machines in a
content addressible store. Duplicated data even on separate
machines will not take additional space. Collisions can be made
arbitrarily improbable by choice of hash function size (not
easily changeable, in the current code, though).
- Pool manager uses Sqlite3 specific capabilities to get efficient
storage of the pool index. Sqlite3 is a custom binding to
Sqlite3 to take advantage of these capabilities.
- Uses openssl's sha1 library. Wouldn't be difficult to use a
different library (there are license issues with openssl).
Generally the program's performance is bound by the speed of
hashing and/or the speed of data compression.
- Uses Duncan Coutts' zlib library to get good zlib speed.
- Linux dependent. Uses the output of '/sbin/blkid' to map
devices to UUIDs of the filesystems to get persistent, and
unique identifiers for each filesystem.
- Has a primitive status display ('-v') during backup.
- Able to backup and restore directories/filesystems. Restore
semantics are as accurate as I can get them without extra
strange semantics.
- Multithreaded backup. Allows backup to run at high speed, even
while waiting for cache responses from the server. Does not
need to be built with '-threaded'.
- Restore is reasonably simple. It tends to get tested less, so
it is beneficial to move complexity to the backup side.