If there were to be a sever crash that wiped your CMS data as well as your site stucture/pages, you would rebuild the site stucture using your last saved good copy which should be on a local machine, and recreate your database (with the same name) and then import your last saved .sql into it in order to re-populate your site pages with the backed up content. Presumably, if all the changes (subsequent to building and uploading your site) were made using the CMS, then the restore would consist of just those two operations. Once the original site is up and working - with all the include code for the different pages and sections' content coded in to the pages, you would have a copy of that saved locally. Just by uploading that whole original site, it would draw upon the current data stored in the database to be up-to-date again.
If you update the site with new or revised menu additions, it would not affect anything entered via the CMS, and you would have those revisions saved as part of your local (DW) site any way. It might be worth considering having your menu structure created as a dynamic menu, with its values stored in the same database as the CMS data. A benefit of this is that if you are restructuring your site and adding pages, you could have the remote database mirrored on a local machine where you could add and test menu items and then export just the menu .sql and import it on to your remote db (along with the new pages containing the CMS include code) with very little down time.
Have just thought of a third operation, - any files (images, mp3s, docs pdf etc.) that were uploaded using the CMS FckEditor/kfm file manager will also have to be backed up occasionally too, as the CMS only records their paths/names and properties to database, - the files themselves are in a directory on your (crashed) server.
You would need to add the pages to the site map yourself, using whatever tool you use to compile it. If you have added fresh pages, then you might already be thinking in terms of running a program like Surveyor to generate up-to-date xml (and html) site maps for submission to search engines anyway.
It's surprising how little the subject of backing up the data created by CMS crops up, gived its importance. Hosted servers will (should) have robust backup/recovery safeguards anyway, but being in charge of your own backups is worth working out a decent plan for, especially if you haven't agreed a plan with your client about whose responsibility it is.