ANN: Lokad.Snapshot released, open source app to backup / snapshot your Azure Storage account RRS feed

All replies

  • Great Work Joannes!

    Love what you have done already!



    Wednesday, August 11, 2010 3:56 PM
  • Mario, thanks for your kind feedback. For the record, the one to praise this time is Christoph Rüegg (member of the Lokad team, and long time C# open source contributor).
    Wednesday, August 11, 2010 4:00 PM
  • Hi Joannes,

    Very cool - just wondering whether you intend on supporting non-Lokad.Cloud tables ? Currently the limitation exists

    • Only supports tables using the FatEntity type of Lokad.Cloud, i.e. tables which are created and accessed using Lokad.Cloud's table storage provider 
    Just /wondering ?

    Wednesday, August 11, 2010 6:22 PM
  • At this point the support for FatEntity only is one of the major limitations of Lokad.Snapshot. Supporting all entities is definitively part of the roadmap. Then, any external help will be welcome here :-). The one difficulty for this matter is the lack of REST-level .NET wrapper for the Table Storage API in the StorageClient library.
    Wednesday, August 11, 2010 7:10 PM
  • The one difficulty for this matter is the lack of REST-level .NET wrapper for the Table Storage API in the StorageClient library.

    Surely this is backwards since the Storage Client API is a wrapper round the RESTful Table Service API. Or is the problem that there is limitedTable Storage support at the level of the StorageClient.Protocol namespace?

    Wednesday, August 11, 2010 7:21 PM
  • Neil, you're 100% on the spot. StorageClient.Protocol does not provide primitive for the Table Storage API. This was part of my Big Wish List for Azure , 6 months ago. Yet, I don't think there has been any progress in this area at this point.
    Wednesday, August 11, 2010 7:43 PM
  • Thanks.

    The technical reason for the limitation to FatEntity is that it simplifies slicing of entity streams to optimally filled entity groups, so we can process them in batches. However, this could easily be extended to support all types by directly accessing the raw xml content in the DataContext's ReadingEntity and WritingEntity callbacks, which could then be measured and accumulated to ensure we don't exceed the Azure table api constraints. It's just not done yet, as we didn't need it internally.

    We certainly intend to support this in the future, but unfortunately I can't name a date just yet.

    Wednesday, August 11, 2010 8:02 PM
  • Joannes -

    Given theextremely limited interest in StorageClient.Protocol - I've only ever seen a couple of posts on it - I suspect extending the Table Services support is not particularly high up the priority list. Since I have no inside knowledge this is purely a guess.

    By the way, congratulations on Lokad winning the Windows Azure Platform Partner of the Year award.

    Wednesday, August 11, 2010 8:25 PM
  • Thank you, Joannes and the Lokad team!

    This comes just in time when we needed to implement a back-up and restore strategy for the blob storage. Will surely give this one a try and let you the experience.

    Wednesday, August 11, 2010 8:40 PM