On 10/18/16, Scott Doctor <sc...@scottdoctor.com> wrote:
> Assume many check-ins occurred with many changes over many
> files. Seems that if something glitches everything can become
> out of sync and hard to recover. My question, is there is a way
> to tell fossil to store the complete versions of the documents
> instead of it recreating the documents by piecing all those
> fragments together. My concern is that something goes wrong,
> perhaps a bad disk sector not necessarily a software issue, that
> would further complicate recover.

Content is checked to make sure it is recoverable prior to running the
COMMIT that stores it in the database.  If any content is not
recoverable, Fossil runs a ROLLBACK instead. See
https://www.fossil-scm.org/fossil/doc/trunk/www/selfcheck.wiki for
further information.

To guard against hardware bugs damaging the database, clone the
database on multiple machines and keep them in sync automatically.
You are more likely to have a complete disk failure or some other
local disaster (a fire or flood) and loss everything than a single bad
sector.  Turning off the delta compression will not save you from a
flood or fire. So if you have important content, be sure to clone the
repo to multiple geographic locations.

The Fossil self-hosting repositories are stored on leased servers
located in three different data centers, each at least 500 miles
distant from the others.  Server space is leased from two different
companies to prevent a common-mode failure at a single ISP.  All
content is kept in sync using cron jobs that runs "fossil sync -u"
very hour or so.  And, of course, there are countless private clones
of Fossil that can also be used for recovery.

There was once a double-bug in Fossil and stunnel that corrupted the
canonical Fossil repository database, breaking the delta chain, and
making downstream content unrecoverable.  The first problem was that
stunnel was launching Fossil without opening file descriptor 2
(stderr).  The database was opened on the first available file
descriptor, which was 2.  Then a bug in Fossil caused an assert() to
fire which did write(2,...) to put an error message smack in the
middle of the database file.  All content was recovered using one a
clone.  SQLite was subsequently enhanced to never open a database
using a file descriptor less than 3 so this error can never happen
again.  But who knows what other subtle problems lurk undetected.
Also clone data you care about.
D. Richard Hipp
fossil-users mailing list

Reply via email to