I. Introduction DotNetNuke is an enterprise framework that allows rapid web development. Just like any enterprise application, proper procedures must be in place for backups and restores. II. Purpose This document will discuss three ways that DotNetNuke is generally backed up as well as advantages and disadvantages of each. A recommendation on proper backup procedures will also be made. III. Rules for Good Backup Solutions Before discussing different backup methods, it is important to have criteria for good backup solutions. Here are three questions we will ask about each of the backup methods: Does it capture all data? (Did I really backup everything?) Is it “Bare Metal” restorable? (Do I have to install my site to restore my site?) Is it universally restorable? (Can the backup be restored on almost any server in the world?) IV. Template Backups The DotNetNuke Core Framework has the ability to do a high-level data export and create what is known as a “Portal Template”. Portal templates were designed as a great way for a web developer to save some time when developing a new website; however, they should never be used as a backup solution. When portal templates are created, the template files only contain a high-level view of the data in the website. For example, portal templates do not include user account information, security roles, or host settings. Portal templates do not actually contain the DNN install information either. Portal templates require a functioning DNN site in order to operate, and a portal template alone will not let you “restore” to anything. Portal templates do not fulfill any of our criteria for a good backup. Portal templates are not backups. Portal Templates were not designed to be backups. Do not use portal templates as backups. V. DotNetNuke Backup Modules An emerging trend is the use of DotNetNuke Backup Modules. This is a module that you install into your DotNetNuke website that allows you to back up your DotNetNuke installation. Although each vendor implements their module differently (this not a good thing), they all suffer from a common set of issues. First, one of the most noticeable problems with a DotNetNuke Backup Module is that it requires a running DotNetNuke website. This is like saying “I’ve made a backup of your computer, but in order to restore it, your computer has to be working fine.” Backup modules require that DotNetNuke is running correctly and have the restore module installed in order to do a restore. Although some backup modules may create an archive of the DotNetNuke website files themselves, a place that all backup modules fall short is the database. If the backup module even “backs up” the database, the database is really exported (bad) into a vendor-specific format that can only be used by sites running with that backup module (bad). VI. Native Backups Native backups are, by far, the absolute best and only way to make a true backup of a DotNetNuke website. A native backup is created by simply making a snap-shot of the website files and database at the same time. The easiest way to do this is to make a ZIP (just a compressed archive) of the entire website and a SQL Server .BAK backup of the database. This is the optimal solution for your DotNetNuke website because all of the data is captured (there is no data export), every computer in the world can open a ZIP File, and every SQL Server can restore BAK database backups. Whether you are backing up your website or changing hosting providers, native backups are the only way to reliably backup your data. There is only one problem with native backups – most hosts will not let you do them. Although all hosts give the ability to download individual files (not a ZIP archive) through FTP, few hosts give the ability to download a database backup. Also, when making a native backup, it is important that the database and website are backed up at the same time – do not use a nightly database backup with a ZIP file you just downloaded. If the backups are not closely synchronized, then you can have post-restore issues if your DNN website is expecting data that does not exist in your DNN database. VII. Conclusion When managing a DotNetNuke site, it is important to have a solid backup plan that reliably packages all of your data in a native format that can be restored to any server. At PowerDNN customers can create and download their own native backups which include a synchronized backup of your website and database, by following these instructions. VIII. General Q & A Q: How often should I backup my website? A: It depends on a lot of things. How important is it? How often does it change? How much work is it to recreate changes? I generally recommend making a snapshot every time you’ve made significant changes to the site. Q: I’m not very technical. How can I get a reliable backup of my site? A: If you trust your hosting provider to do it right, just ask them. Q: I’ve used a backup module in the past and it worked fine for me. Why should I change? A: Just because a backup module happens to make a backup, doesn’t mean that it can reliably do a restore. Even if it happened to work for you, it is still a very poor option. I have seen countless people with other hosting companies completely lose their website because they were relying on a backup module to save them. I have never seen someone with a valid ZIP archive and valid SQL BAK file that isn’t able to restore. Q: What is the best way for me to know if I have a good backup? A: Do a restore from a blank website. Remember - You have not have a backup until you have done a restore