Your organization's deployment of Dynamics AX is going to be one of the most important applications in your enterprise (if not, it is the most important application). It is absolutely critical to the health of your business that a sound backup and restore strategy is in place for your implementation of Dynamics AX.
Ensure that full database backups are occurring on your database server and that all databases (user and system databases), not just your AX business database and model database, participate in the backup schedule. If your organization has a very large AX business database, a nightly full database backup may not be practical due to the amount of time it takes for a full database backup to complete. If this is the case, also ensure that differential backups are being performed; this type of backup captures all of the changes that have occurred since the last full database backup. Another type of backup that is essential to your organization's backup and restore strategy is the transaction log backup, which should be ran in frequent intervals (5-15 minute intervals is fairly common); the transaction log of a database is a file that contains log records of the transactions that take place. Backing up the transaction log allows the administrator to roll forward the changes (when restoring the log backups) to recreate the precise state of the database when the log backup started.
Equally important in having a sound backup methodology in place is the restoration piece of the whole strategy. Regularly-occurring database restores to lower environments (DEV, TEST, UAT, etc.) is commonplace. I have participated in many IT audits, and this surprisingly satisfies audit requirements. However, simply restoring a full database backup on a regular basis (along with any differential backups) is not enough. If your organization is performing nightly full backups, you can only restore up to the previous night's full backup; the transactions that have taken place after the full backup are not accounted for. And, if your organization is leveraging differential backups, all transactions that have taken place after the newest differential backup are also not accounted for. Being able to restore the transaction log backups is a must because restoring these backups is the only way to establish point-in-time recovery. And, in the event of a failure with your organization's AX deployment, more than likely it will not be acceptable to the business to only be able to recover to the previous night's full backup or latest full backup and differential backup set.
Something also to consider is the location of the backups. If the databases and backups reside on just a single SAN, for example, and the SAN suffers from unrecoverable failure, your database server along with the databases are gone -- along with the backups. Collaborate with your storage administrators to ensure that a high-availability solution is in place for your organization's storage devices. Besides SQL Server, you will want to make sure that there is a solid plan in place for backing up and restoring the rest of your ERP stack (AOS servers, RDS, SSRS, SharePoint, etc.).
Lastly, having detailed documentation over the entire backup and restore strategy that is reviewed and tested thoroughly and regularly will help ensure the recoverability of your Dynamics AX implementation.