Hi v-gchenna-msft,
I have been redafing the blog you mentioned aloingside and the official MS docs about Fabric disaster recovery. My conclusion after carefully reading both is that data recovery on Fabric data engineering (WH & LH)) mainly relies on delta table capabilities to restore a table at a specific point in time using time travel.
To take leverage of delta tables timeline capabilities for managing data recovery scenarios is not bad on its own, but (and this is my main concern) this approach misses other disaster recovery scenarios where restoration is required at item level (whole warehouse/lakehouse, tables/views/ storeprocedures/notebooks).
How to proceed if a table/view/store procedure has been completely removed from the WH? Or even worse , what about the whole WH/LH as has been "accidentally" dropped?
In such a cases MS docs provides 2 options
1) make use of "Disaster recovery capacity setting" to keep a copy of all Fabric items (which includes WH/LH) on a secondary region. OK, this may work, but sounds to me as using a sledgehammer to crack a nut. (Leaving aside the extra cost)
2) Another suggestion option is keep WH code (table, view, stored procedure) versioned and saved in a safe location (such as Git). I certainly prefer this last one, but git is primarily a version control system rather than a traditional backup tool.
In summary, imho MS provides workarounds on Fabric for managing disastery recovery scenarios but any of them might be fully considered as "actual" backup methods (at least as I understand them).
I firmly belive that MS should consider for future Fabric releases some kind of pure-backup mechanism (not based on tables timeline or versioned git code)
Regards,
Alfons
Thanks,
