FSVS
Purpose
FSVS is the abbreviation for “Fast System VerSioning”,
and is pronounced [fisvis].
It is a complete backup/restore/versioning tool for all files in a
directory tree or whole filesystems, with a
subversionTM
repository as the backend.
You may think of it as some kind of tar or rsync with versioned storage.
Description
FSVS is now a mature project. Its automated self-tests have more than
90% code coverage, and try to break FSVS in many different configurations
(running as user or root, different locales [eg. UTF8/ISO8859-1] or
repository-access protocols like http:// or file://).
Currently it does (in terms borrowed from subversion)
- checkout/initialize itself for operation (define target URL)
- commit to this URL (backup), with meta-data support (owner,
group, mode, devices, symlinks)
- show the status, ie. which entries have changed, and what was
changed (data or meta-data)
- diff single files local/remote/remote
- revert single files to the repository version
- update from this URL (restore), with meta-data support
and merging of local changes
- use advanced ignore patterns, eg. to ignore all virtual
filesystems like /proc, /sys, /dev (if devfs), and so on.
PCRE-expressions and recursive ignore patterns are possible, too.
- updating from more than one URL (overlayed, like unionfs)
- currently testing: automatically detecting copied/moved files
- re-synchronize with the repository (for recovery)
- FSVS understands some special properties for backup handling, eg.
to define transparent en/decryption; see the
commit-pipe special property.
But it still gets new features; if you want/need something, don't hesitate
to ask on the mailing lists - maybe it's already implemented!
Roadmap, in descending order of priority (but without any guarantees):
- xattr support
- delta transmissions - to and from repository (CPU vs. bandwidth)
- tag and branch commands (proposal)
- rework into a library? API compatible to libsvnclient, to make it directly
useable from subversion working copy browsers?
If you're missing something, just ask.
A nice capability is to cope with local adjustments for
different machines (using branching-like techniques), so that most of the
space needed for the backup of system-files (/bin, /usr, ...)
can be shared between machines.
Read more about how it should work, and its
differences to the subversion client
svn.
Documentation
You can browse through some (text-only) documentation
here -
this is the same as available in the source packages.
A bit more to read is the (Doxygen)
generated documentation;
while this is mostly interesting for developers, there's a module for users
as well here
- there you'll find such things as command
line parameters, ignore
patterns, and the url
format.
Another help might be the
backup HOWTO, or some other HOWTOs
.
If you prefer, you can download the full documentation packaged from
here.
Thomas Harold wrote a bit about his setup and usage of FSVS in
his blog.
Download
The releases are available below the "Documents & Files" link on the left side;
please click on the directory to browse it, simply clicking on the + doesn't show
the files inside. Here's a link
to the current version.
Communication and contact
There are two mailings lists, which are archived in gmane too
(users,
dev).
Furthermore there are two IRC channels,
#fsvs and #fsvs-dev, on irc.freenode.net.
User comments
... fsvs kicks some serious ass. ;)
Backing up ones data has never been so much fun before. :-)
Thanks a lot for your hard work!
I'd also like to thank you for creating fsvs. I've only been using it
for a little while, but it's already clear that it will make system
upgrades or recovery from hardware failure a lot less painful.
Related
There's svntar, which can generate a
tar file directly out of a subversion repository.
Currently it's being extended to use the FSVS meta-data properties, too.
Statistics
It's released under the GPL; the project has seen about 800 hours of work
as of Oct 2007 and has currently about 8600 lines of code,
excluding comments, empty lines and test scripts.
Test coverage is currently better than 91%; if the error handling lines that
cannot easily be tested (like doing ENOMEM, ENOSPC etc.)
are counted as executed, it goes up to 94%.
There's a tool called
sloccount
(in debian as package available); this says
Totals grouped by language (dominant language first):
ansic: 11551 (97.16%)
perl: 279 (2.35%)
sh: 59 (0.50%)
Total Physical Source Lines of Code (SLOC) = 11,889
Development Effort Estimate, Person-Years (Person-Months) = 2.69 (32.29)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.78 (9.36)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 3.45
Total Estimated Cost to Develop = $ 363,533
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."
Supported by