The company I work for is currently going through a NAV 2009 implementation. We’ve decided on the RTC client as we are going to have somewhere between 100-200 users on the system and believe that it will provide us a better user experience in the long run.
We’ve not yet been able to find acceptable answers to the following questions and I’m wondering if someone can help. I’ve searched here and on the net as a whole (that’s how I found this site) but no results have come up that are useful to me thus far. We’ll be using SQL 2005 as our DB.
What are the typical backup strategies that are suggested with NAV that provide the best availability, performance, and disaster recovery? We’re a distribution company and would want to have minimal downtime or lost data during disasters,
Does NAV have built-in archival tools? We’d want to archive records older than X days on a daily basis to another DB so that the main system is always running optimally. I have yet to find any clear answers on this yet. I guess if not an option would be to write SQL jobs to do this but I’m sure that would be a small project in itself given the number of tables within NAV and having to undersatand the relations beteen data.
Thanks in advance!
Welcome to the “Dynamics User Group” [<:o)]
Well, the optimal Backup Strategy actually depends on your needs regarding maximum Server Downtime and max. acceptable Data-Loss. Further it depends on the available storage capacities to save the backups.
So just a few “thoughts”:
- ONLY CREATE SQL BACKUPS - NEVER USE THE PROPRIETARY NAV BACKUP FEATURE
- One Full-Backup per Day is mandatory
- Create Transaction Log Backups; their frequency determines the max. data-loss
- On large systems with high transaction volume maybe Differential-Backups every couple of hours might be feasible
- In addition to the backups you may implement some failover solution, like Clustering, Mirroring or Log-Shipping. See SQL “Books Online” about details.
Yes, there are some, but those are not always really “practicable”. The problem with pure SQL jobs is, that archiving might require some business logic, which hardly could be reproduced with SQL. IMHO archiving and data-cleanup is a premanent problem with NAV … So you and your NAV partner should develop an archiving-concept that suits your needs, maybe mixing NAV standard features with your own procedures … but handle with care …
Thanks for the response. We’ll take all of it into consideration - the archival issues are troubling to us though.
Thanks for this forum… im also an Sql user maybe…admin or IT support… its so difficult to maintain daliy back up of SQL dtabase coz its so big file and it almost… filled my 1terabyte hdd in 1mos…
i HOPE ican learned more… knowledge how to handle SQL back ups ang SQL support… jus 2005 sever…
“its so difficult to maintain daliy back up of SQL dtabase”
Seriously? Then you are keeping too many backups on site or you need to tell your employer to buy another disk [:)]
Anyway, NAV does NOT have built in data archival features. You should think carefully about this, though. SQL can handle a lot of data. We run a 100 GB database with over 100 users on SQL 2000 and only experience occasional blocking. I have done data archival projects, though, and yes, they are a bit of work to accomplish. Personally I would only archive data once a fiscal year was closed. And even then only data older than a few years, not days. And only if the company absolutely had to. But that’s me.
wow,its very nice to hear that…sir…
in my case there are 3 sql server which is now implemented and 1 of this data base is handle a daily sales posting and etc… so the daily growth of data is faster… what i need is to handle the whole year transaction …with out slowing down the system…my users are 30 up only… daily…log in… night posting and nightly making back up… wITH fbk EXtension…not the sql back up …method…
thanks…you very much…waiting for reply…