HISTORY

Ma.gnolia, 30 January 2009: the Copy That Was Not a Backup

Ma.gnolia lost every member’s collection in a single morning because the thing it called a backup was a file sync with no versioning, no integrity checking and no restore ever performed.

Published 2026-08-06 · Updated — · 2,821 words · 16 sources · Status of facts checked 2026-08-06

On the morning of Friday 30 January 2009, the social bookmarking service Ma.gnolia stopped returning bookmarks. Wired reported the same day that the service had lost its primary store of user data and its backup together, and reproduced the notice its founder, Larry Halff, had put on the homepage: the service was offline, members’ bookmarks were unavailable through both the website and the API, and the process would take “days, not hours.”¹

Eighteen days later, at 10:50 AM PST on 2009-02-17, the same page carried a different sentence. Database file recovery had been unsuccessful; members’ bookmarks would not be recovered from the Ma.gnolia database; the public recovery tools were the only remaining source.² Data Center Knowledge reported two days later that Halff had put the size of the service’s MySQL database at nearly half a terabyte, and that a specialist had been unable to recover any data from the corrupted drive.³ Chris Messina, who recorded the podcast episode in which Halff described what happened, wrote of “over half a terabyte of data.”⁴ The order of magnitude is agreed across those sources; a single exact figure could not be verified.

What the episode is remembered for is a phrase: no backup. That phrase is the title Backblaze gave its account of 2009-03-02.⁵ It is also the least useful description available, because a copy did exist. Reading the contemporaneous sources against each other separates at least three distinct failures, each of which had to occur for the outcome to be total. Any one of them fixed on its own would have changed what members got back.

Failure one: the copy was a mirror, so corruption propagated into it

The arrangement is described consistently in two 2009 sources: a file synchronisation over FireWire to a second machine.⁵⁶ Colin Charles, writing on 2009-02-24, took notes from the podcast and recorded the mechanism plainly: the backup was backing up corrupted data.⁶

This is the difference between a mirror and a backup, and it is a difference in one property: retention. A synchronisation run makes the destination resemble the source as the source is now. When the source is intact, the destination is a copy. When the source has been damaged, the next run propagates the damage and overwrites the last undamaged state. A mirror can answer the question “what does the database look like”; only a versioned backup can answer “what did the database look like before the thing that broke it.” A restore needs the second question answered.

There is a second, independent problem with copying a database this way, and it applies even when nothing is corrupt. MySQL’s manual states that to get a consistent backup by copying table files the server must be stopped or the relevant tables locked and flushed, and warns that table file copying methods do not work if the database contains InnoDB tables, and that InnoDB may still have modified data cached in memory and not flushed to disk.⁷ A file sync running against a live MySQL data directory copies whatever the files contained at the instant each was read. The result is a set of files, not a database in a known state. Charles’s note that the backup “didn’t backup the data from mysql” is that same observation, made from the outside.⁶

Failure two: nothing verified either copy, so the damage had no discovery date

The second failure is the one that decides how much a versioned backup would have been worth, and it is usually skipped. According to Charles’s notes of Halff’s account, the service kept running while corruption was already present, and the site went down afterwards.⁶ The outage was not the corruption. The outage was the discovery of the corruption, at an unknown remove from its start.

That gap is what an integrity check exists to close. Without one, a copy has no known-good date attached to it, and a known-good date is the input a restore actually consumes: a restore is a choice of which stored state to return to. With retention but no verification, the operator faces a shelf of copies and no way to say which of them predate the damage. With verification but no retention, the operator learns the damage is present and has nothing to fall back to. Ma.gnolia had neither.

At the storage layer, the difference was not hypothetical in 2009. Mark Callaghan, commenting on Charles’s post the day it went up, set it out: InnoDB always checksums pages, MyISAM can but does not by default, and the checksum does not prevent the corruption but may help spot the problem sooner.⁶ MySQL’s manual documents the same asymmetry from the other side: a live table checksum is what a MyISAM table created with the CHECKSUM=1 clause returns, and by default the entire table is otherwise read row by row and the checksum calculated.⁸ Which storage engine Ma.gnolia’s tables used could not be verified. Charles replied in his own comment thread that he suspected MyISAM and would pass on anything the service told him; as of 2026-08-06 the post carries no such update.⁶

Failure three: no restore had ever been performed

The third failure is the one that makes the first two invisible in advance. Backblaze’s account states it directly: the system was never tested to see if the backups worked, and when it came time to restore, they did not.⁵

An arrangement that has never been restored from is not a backup; it is a hypothesis about a backup. Everything that can be known about it before a restore — that the job runs, that the destination fills up, that the file count looks right — is compatible with total failure. The first restore Ma.gnolia performed was the one performed under load, on the only day it mattered, and the sequence is preserved on the service’s own status page: on 2009-02-06 a set of public bookmarks extracted from a cached copy of the site; on 2009-02-09 a further tool for members who had used the scheduled blog-posting system; on 2009-02-13 word that the data-recovery firm was still working; on 2009-02-17 the announcement that it had not worked.²

Eighteen days is a long test cycle. Run once a quarter against a scratch machine, the same test costs an afternoon and returns a date.

What came back came from outside the service

The recovery routes that returned anything have one property in common, and it is the property this publication exists to record: every one of them drew on a copy held somewhere other than Ma.gnolia.

FriendFeed. On 2009-02-03 Wired described an automated tool at recovery.ma.gnolia.com that asked a member for a FriendFeed nickname and remote key and gathered up what they had saved by querying FriendFeed. It worked only for members who had connected the two accounts before the failure.⁹
Feeds and aggregators. Halff’s letter told members who had published their bookmarks through RSS feeds or aggregation services to re-capture what they could before those feeds expired.²
Search-engine and site caches. The 2009-02-06 tool was built from a cached copy of the public Ma.gnolia site; the notice of 2009-02-08 states there were then more than twice as many bookmarks in it as on 2009-02-06. Data Center Knowledge names the Google cache among the public tools members were left with.²³

Stated as a rule rather than an anecdote: the recoverable fraction of a member’s collection was the published fraction. Ma.gnolia let members mark bookmarks private, per Wikipedia’s description of the service, cited here as a secondary source.¹⁰ A private bookmark has no copy in a search cache, no entry in a public feed and no line in an activity stream. The recovery tools could not reach it, and nothing else could either.

The same logic disposes of the feature that would seem to protect against exactly this. Wikipedia records that, unlike Delicious, Ma.gnolia stored snapshots of bookmarked web pages¹⁰ — the property that makes a saved link survive the death of its target. Those snapshots lived in the store that failed. A copy held by the same party that holds the original is exposed to the event that takes the original.

What the service could still do, it did on a stated schedule: Halff’s letter of 2009-02-17 committed to refunding premium feature subscriptions within two weeks, and pointed members who wanted to start a new collection at Diigo.²

What is in the archive now, and how to count it

Seventeen years later the largest surviving body of Ma.gnolia material is the Internet Archive’s, and its size is measurable rather than a matter of impression. The following counts come from the Wayback CDX API, retrieved 2026-08-06, using this query shape, with the path prefix substituted:

https://web.archive.org/cdx/search/cdx?url=ma.gnolia.com/people&matchType=prefix&filter=statuscode:200&fl=timestamp,original&collapse=urlkey&limit=400000

ma.gnolia.com/people — 287,567 distinct URLs with at least one HTTP 200 capture, of which 284,056 were first captured before 2009-01-30. After percent-decoding and lower-casing, those URLs resolve to 19,657 distinct first path segments below /people.
ma.gnolia.com/groups — 50,051 distinct URLs, across 2,619 distinct group segments on the same normalisation.
ma.gnolia.com/bookmarks — 28,783 distinct URLs, of which 67 end in /snapshot.
recovery.ma.gnolia.com — 55 distinct URLs, and they are not one thing. Sixteen are the recovery service, captured between 2009-02-07 and 2009-04-18: the FriendFeed form, the web-cache tool, the feed and blog-posting recovery tools, and a small number of individual members’ recovered-bookmark output files in HTML, CSV and XML. The remaining thirty-nine are dated 2015-08-01 to 2015-11-01 and are stylesheets, scripts and images belonging to an unrelated site served at that hostname six years later. This publication does not reproduce the 2009 output files and does not link to any of them.

Three cautions belong with those numbers. collapse=urlkey counts distinct URLs, not captures, so the figures understate how many times any page was taken. A status code of 200 is not a guarantee of the content a reader would expect: a capture taken under /people on 2009-02-01 returns Halff’s notice rather than a member page, which is why the pre-failure figure is given separately. And a capture of a member page is a copy of what that page showed the public, not of the collection behind it.

What survives is lopsided in a specific direction: the most public material — group pages, tag listings, member pages linked from elsewhere — is the most fully represented, and the private half of the service is absent from the record entirely. That is the same selection the 2009 recovery tools made, applied by a different mechanism.

The second ending was an ending; the first was a loss

Ma.gnolia returned in September 2009 as a small invitation-only service running basically the same software, described by Halff in a CrunchGear interview published 2009-09-21.¹¹ After a request from the makers of the Magnolia content management system it was renamed Gnolia in October 2009, per Wikipedia.¹⁰ In September 2010 Halff posted a closing notice: the service would go into read-only mode on 2010-09-29 and remain available for bookmark exporting until at least 2010-11-30.¹²

The two endings differ by one thing, and it is not the emotional register. It is a number: sixty-two days of export against zero. That number is the whole of the difference between a service closing and a collection being destroyed, and it is the variable this site’s Ledger records per service. Furl shut down on 2009-04-17 and its bookmarks were migrated into Diigo.¹³ Pinboard bought Delicious on 2017-06-01 and put it into read-only mode on 2017-06-15, telling users explicitly there was no time pressure to move.¹⁴ Mozilla announced Pocket’s closure on 2025-05-22, stopped the service on 2025-07-08 and kept exports open until 2025-10-08.¹⁵ Ma.gnolia’s January 2009 members had no such interval, because the interval is a property of a planned shutdown and not of a failure.

On the founding year, which this publication does not assert

Ma.gnolia’s founding year circulates as both 2005 and 2006, and the sources disagree because they are dating different events. TechCrunch published a pre-launch notice on 2005-10-22 in which the service was collecting email addresses from people who might be invited to a beta launch promised for December 2005.¹⁶ The earliest capture of ma.gnolia.com in the Wayback Machine returning HTTP 200 is 2005-10-13, which bounds the domain’s existence and is not a founding date. Halff’s own letter of 2009-02-17 says the service was approaching the third anniversary of its public launch, and that he had given the project nearly four years.² Messina, writing the day before, put the start of the project four years earlier as well.⁴ Those statements are consistent with each other: work from about 2005, a public launch in 2006. Wikipedia’s infobox gives 2006 and cites the October 2005 pre-launch post for it.¹⁰ No single founding year is asserted here; the entry sits on this site’s published do-not-assert list.

What the case leaves behind

Of the 50 names on the 2007 roster captured at this address, 8 still offer somewhere to save a link, 1 survives read-only, 11 are documented as shut down and 30 could not be verified (checked 2026-08-06). Ma.gnolia is in the eleven. Its members’ data went on 2009-01-30; the service that held it closed at the end of 2010, nearly two years later.

Three conditional rules, tied to the three failures, and stated as rules about copies rather than advice about products:

A copy without retention is a mirror. It answers what the source looks like now, which is the one question a restore never asks.
A copy without verification has no known-good date. Retention without verification produces a shelf of candidates and no way to choose among them.
A copy that has never been restored from is an assumption. The cost of converting it into a fact is one scheduled restore into a scratch environment; the cost of not converting it is discovered at read time, which is always the worst time.

And the transfer to a reader who runs no servers: a service holding the only copy of a collection occupies exactly this position on that reader’s behalf, with the same three properties unknown, and it is under no obligation to publish which of them it has. The half of Ma.gnolia that survived January 2009 is the half its members had already pushed somewhere else.

Where to find it now

ma.gnolia.com — the service: Gone. The Wayback Machine holds captures of the root from 2005-10-13 to at least 2017-10-25, and captures under /people, /groups and /bookmarks as counted above. Data on shutdown, January 2009: irretrievable — no export was offered and no member export survived the failure. Data on shutdown, 2010: exportable, with a window from 2010-09-29 to at least 2010-11-30. The domain itself resolves and returns HTTP 200 from an nginx server (checked 2026-08-06 against the public resolvers at 1.1.1.1 and 8.8.8.8). What is served there is not a bookmarking service: no sign-in, no member page, no API and no export endpoint. What that page is, and who operates the domain now, could not be verified and is not described here.
recovery.ma.gnolia.com — the 2009 recovery tools: Gone as a service. Sixteen distinct URLs belonging to the recovery tools carry at least one HTTP 200 capture, dated 2009-02-07 to 2009-04-18, including the FriendFeed form, the web-cache tool and the blog-posting recovery tool. Individual members’ output files are among them and are neither reproduced nor linked here. A further thirty-nine URLs under the same hostname, captured 2015-08-01 to 2015-11-01, belong to an unrelated later site and are not recovery material.
The 2009-02-17 announcement: Preserved in the Wayback capture of the Ma.gnolia status page taken 2009-02-18, which carries the dated notices from 2009-02-06 onward in one page. This is the primary record for the recovery sequence.
The Gnolia closing notice: Preserved in the Wayback capture of gnolia.com/pages/closing taken 2010-11-23, which states the read-only date and the export window. The page carries no date of its own; the earliest capture of it is 2010-09-27.
The Wired reporting of 2009-01-30 and 2009-02-03: Both articles are live. The URLs under which they were published in 2009 return HTTP 404; both are served at a shortened path on the same host and returned HTTP 200 (checked 2026-08-06). Those are the URLs cited below.
Citizen Garden episode 11, the podcast in which Halff described the failure: The podcast’s own domain, citizengarden.com, redirects to a HugeDomains for-sale listing, and the episode’s Vimeo page returned HTTP 200 to a request (both checked 2026-08-06). The written record of its technical content is Chris Messina’s post of 2009-02-16 and Colin Charles’s notes of 2009-02-24, cited below.

References

Calore, Michael. “Ma.gnolia Suffers Major Data Loss, Site Taken Offline.” Wired, 2009-01-30. https://www.wired.com/2009/01/magnolia-suffer/ — retrieved 2026-08-06. ↩
Ma.gnolia. Status page carrying Larry Halff’s dated notices of 2009-02-06 to 2009-02-17. ma.gnolia.com, 2009-02-17. https://web.archive.org/web/20090218045324/http://ma.gnolia.com/ — retrieved 2026-08-06. ↩
Miller, Rich. “Ma.gnolia Data is Gone For Good.” Data Center Knowledge, 2009-02-19. https://www.datacenterknowledge.com/business/ma-gnolia-data-is-gone-for-good — retrieved 2026-08-06. ↩
Messina, Chris. “What really happened at Ma.gnolia and lessons learned.” Factory Joe, 2009-02-16. https://factoryjoe.com/2009/02/16/what-really-happened-at-magnolia-and-lessons-learned/ — retrieved 2026-08-06. ↩
Budman, Gleb. “Ma.gnolia Wilts with No Backup.” Backblaze, 2009-03-02. https://www.backblaze.com/blog/magnolia-wilts-with-no-backup/ — retrieved 2026-08-06. ↩
Charles, Colin. “On Ma.gnolia, and data recovery.” Colin Charles Agenda (bytebot.net), 2009-02-24; including the comments by Mark Callaghan and by the author, both dated 2009-02-24. http://www.bytebot.net/blog/archives/2009/02/24/on-magnolia-and-data-recovery — retrieved 2026-08-06. ↩
Oracle. “Database Backup Methods.” MySQL 8.4 Reference Manual, n.d. https://dev.mysql.com/doc/refman/8.4/en/backup-methods.html — retrieved 2026-08-06. ↩
Oracle. “CHECKSUM TABLE Statement.” MySQL 8.4 Reference Manual, n.d. https://dev.mysql.com/doc/refman/8.4/en/checksum-table.html — retrieved 2026-08-06. ↩
Calore, Michael. “Ma.gnolia Using FriendFeed to Restore Users’ Data.” Wired, 2009-02-03. https://www.wired.com/2009/02/magnolia-using/ — retrieved 2026-08-06. ↩
Wikipedia contributors. “Gnolia.” Wikipedia, n.d. Cited as a secondary source. https://en.wikipedia.org/wiki/Gnolia — retrieved 2026-08-06. ↩
Donovan, Jay. “Interview: A conversation with Larry Halff about the relaunch of Ma.gnolia.” CrunchGear, 2009-09-21. https://techcrunch.com/2009/09/21/interview-a-conversation-with-larry-halff-about-the-relaunch-of-ma-gnolia/ — retrieved 2026-08-06. ↩
Halff, Larry. “Farewell.” Gnolia, n.d. https://web.archive.org/web/20101123161730/http://gnolia.com/pages/closing — retrieved 2026-08-06. ↩
Wikipedia contributors. “Furl.” Wikipedia, n.d. Cited as a secondary source. https://en.wikipedia.org/wiki/Furl — retrieved 2026-08-06. ↩
Cegłowski, Maciej. “Pinboard Acquires Delicious.” Pinboard Blog, 2017-06-01. https://blog.pinboard.in/2017/06/pinboard_acquires_delicious/ — retrieved 2026-08-06. ↩
Espósito, Filipe. “Mozilla announces shutdown of Pocket.” 9to5Mac, 2025-05-22. https://9to5mac.com/2025/05/22/mozilla-announces-shutdown-of-pocket/ — retrieved 2026-08-06. ↩
Arrington, Michael. “Ma.gnolia: More Social Bookmarking.” TechCrunch, 2005-10-22. https://techcrunch.com/2005/10/22/magnolia-more-social-bookmarking/ — retrieved 2026-08-06. ↩

Notes

The CDX counts above were taken with a single request per path prefix and a limit high enough to return the full result set; the /people query returned 287,567 rows against a limit of 400,000, so it is not truncated. Path segments are counted after percent-decoding and lower-casing, because the raw strings contain the same names in several encodings; counted raw, the /people figure is 19,732. A reader repeating these queries on a later date should expect larger numbers, since the Archive continues to acquire captures of pages that link into these paths.
The closing notice at gnolia.com/pages/closing carries no publication date. It is dated to September 2010 here because it states that read-only mode was a week away on 2010-09-29, and because the earliest Wayback capture of it is 2010-09-27. Wikipedia’s citation of the same page gives 2010-09-22; that date was not independently confirmed.
The sixty-two-day figure for the 2010 export window is the interval from the read-only date to the stated minimum end of exporting. The closing notice says “at least” 2010-11-30, so the true window may have been longer; how long it actually stayed open could not be verified.
Nothing in the 2009 sources establishes how long the corruption existed before 2009-01-30. That interval is the quantity an integrity check would have produced, and its absence is the reason it cannot be given here.
An earlier check recorded that ma.gnolia.com did not resolve. A re-check on 2026-08-06 returned an address from two public resolvers and HTTP 200 from the host. The Ledger row is corrected to match this article, which is the later check.