Clarification about inaccurate information included in a recent article about “DotNetNuke Backup Solutions” (by Tony Valenti), included in “DotNetNuke Newsletter Vol. III, Number 8” (http://www.powerdnn.com/R3/Support/Papers/DotNetNukeBackupSolutions/tabid/189/Default.aspx).

 

Introduction

First of all, and just in case, let me clarify that the ISP’s backup solution described on this article looks great. Useful and well implemented. My opinion is based just on what I’ve read on the paper because I didn’t try the solution.

I completely agree in that the best database backup option is a SQL Server native backup. Nobody can disagree with that.
If fact, when the hosting service is compatible, we advice BackupNative over BackupScript, because BackupNative perform SQL Server’s native database backups.
The free version of BackupNative can backup the database without any restriction.

I don’t want to turn this “Clarification about inaccurate information” into an advertise. Thus, I will not say what else can nor cannot BackupNative or BackupScript modules do. You can check our site (www.evotiva.com) for more information about them.

This post is not a discussion about if an ISP’s native sql backup solution is better or worst than our native or scripting solutions. It’s obvious that when well implemented, a native ISP’s backup solution will be better (there is more ‘power’ and control available at server side).

This post is not a discussion at all. I just want to clarify inaccurate information about our modules that was included in Tony’s article.

BTW, on August 30 I’ve emailed all this information to Tony and I hope he’ll fix his article soon.

 

[quote]
one of the most noticeable problems with a DotNetNuke Backup Module is that it requires a running DotNetNuke website
Backup modules require that DotNetNuke is running correctly and have the restore module installed in order to do restores
[/quote]
This is not true for BackupScript module, which can create/rebuild/restore a site from scratch. No running DNN is required to rebuild a site

 

[quote]
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).
[/quote]
This is not true for BackupNative, which can backup/restore native sql server backups (on some compatible ISPs only, of course)
This is not true for BackupScript, which writes standard “.sql” files which you can edit, modify and even manually run.

Any constructive (and based on accurate facts) thought will be highly appreciated. We are committed to the evolution of our modules.