Lightweight Backup for Entity Framework data: XML, MDF or DB?

I've been tasked with creating a lightweight backup of some of our entity framework data which would enable the maintenance of a bare-bones service in the event of total DB breakdown. It's "lightweight" in the sense that only a tiny sub-set of data is required for this, not in the sense that it won't see much work.

The class that interacts with this data has an Interface that I can use to determine whether or not I need to talk to the full DB or the "light" backup and implement methods accordingly. So, for exampl开发者_开发知识库e, the "save" command is on the interface rather than the data classes and so it can perform either a simple Entity Framework SaveChanges() or something more complex. In other words I don't have to use Entity Framework to interact with the "light" version of my data, although it'd make my life a lot easier if I could.

The question really is that I have no idea how best to perform this "light" backup. I can save the data as an XML file in need be, or an MDF direct from the database. I don't think I'll have an actual live DB to work with. But I don't know anything about the benefits or problems of either approach, or even if they're technically possible.

Suggestions welcome!

---

I think ultimately where you'll end up with this is writing your own EF Provider (see here and here). By writing your own provider, you can have extremely fine control over what happens, and possibly even shunt it to Xml (though I'm not sure whether that's possible...EF is all about SQL generation).

Once you have that provider, you can generate EF code just like with anything.

Having said all of this, I think all of this effort is much better spent building a reliable infrastructure. If you're worried about the db collapsing under load, mirror it across multiple db servers and spread the load horizontally.