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.
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
FSVS is 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://).
You can browse through some (text-only) documentation
this is the same as available in the source packages.
A bit more to read is the (Doxygen)
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
Another help might be the
backup HOWTO, or some other HOWTOs
If you prefer, you can download the full documentation packaged from
here, see "Downloads".
Installation instructions, along with a list of distributions including FSVS, are at the
Thomas Harold wrote a bit about his setup and usage of FSVS in
Please use the freshmeat
page to get the sources; or, if that isn't reachable for you, look at the download page.
Communication and contact
There are two mailings lists, which are archived in gmane too
Furthermore there are two IRC channels,
#fsvs and #fsvs-dev, on irc.freenode.net.
... 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.
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.
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
(in debian as package available); this says
Totals grouped by language (dominant language first):
ansic: 16604 (96.56%)
perl: 591 (3.44%)
Total Physical Source Lines of Code (SLOC) = 17,195
Development Effort Estimate, Person-Years (Person-Months) = 3.96 (47.58)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 0.90 (10.85)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 4.39
Total Estimated Cost to Develop = $ 535,567
(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'."