document version 2007.12.11
BackupScript DotNetNuke Module
Portal Contents Backup Options
What if I cannot script the database objects?
How-To recover my site when I don't have access to DMO or SMO
Case I – Already running DNN site
Case II – Empty / new DNN site
Case III – Empty / new DNN site without the database objects creation scripts or dataprovider files
END USER LICENSE AGREEMENT (EULA)
BackupScript allows you to perform a full site backup & restore
(no matter if the database is local or remote):
the database (any size is supported, all BLOB columns are supported) plus all files
and folders on the site (including \portals, \bin, \desktopmodules, web.config file,
etc.).
The database is scripted as standard, commented and readable .SQL files!. The module
can build all the database objects and recreate the data.
The backup can be scheduled, among other options.
Note: if you want a native SQL Server backup of your database, you may be interested in the BackupNative module.
Please review the companion "Quick Guide" document for a simplified backup/restore procedure.
Our first publicly released module GrupoSur.BackupLite (now Evotiva.BackupNative) is great performing native SQLServer database backups (among other useful features).
Now we wanted a tool that allows us to create/update/replicate all site contents (database and files) with minimal intervention of the ISP.
This module is that tool. If you have a backup of your site built with it, you just need an already created database (empty or not) and the empty (or not) web site (with the necessary write permissions set for the asp.net user) to fully restore/replicate your site.
FREE fully functional for localhost domain, no license required.
Full site backup: database plus all files and folders on the site (including \portals, \bin, \desktopmodules, web.config file, etc.).
Restore utility: allows you to "build/rebuild
your database objects and/or data, with or without DNN installed/running. You need
a valid license to restore the database on any not 'localhost' domain.
The restore utility also allows you to restore your \Portals branch.
FREE stored procedures validator utility
FREE table's PK validator utility
Any database size is fully supported. The module can deal with huge database containing huge Blob data (ready for the new DNN's protected storage).
Database objects scripting (FREE feature, no licensing needed
to freely use it)
The module can generate standard "sql" scripts of your database objects. See "How does it works" section for details.
Database table’s data scripting.
The module can generate standard "sql" scripts for each table’s contents. See "How does it works" section for details.
No ftp access required for your database backup needs.
No administrative rights required.
Enabled direct download of the last generated (compressed or not) backup files.
Scheduled backups are enabled: Every time you configure the module
settings, a scheduled task is automatically configured (with optional email notifications
of successful or failed backups).
You don’t need any administrative right to configure your scheduled task options.
You can configure it directly from the module settings.
Optionally, date & time appended to each backup. Each backup operation will produce a different backup file.
Automated configurable deletion of older backup files.
Configurable compression level for the compressed ZIP files creation.
Backup History Manager: DNN File Manager like dialog, where you can download, delete or restore any backup found on the configured backup folder.
Configurable process priority for the backup thread.
Simple and flexible licensing installation and policy
And more. Please try it FREE and check by yourself.
TIP: Combine the FREE feature of database scripting with the FREE WinMerge tool and you get a FREE database structure comparison tool.
TIP: You can backup/restore from/to different SQL Server versions! That is, you can e.g. backup on SQLServer 2000 and restore on SQLServer 2005
Download the PA from Evotiva's download page.
Install the module as any regular standard DNN module.
You should manually add it to any page (like any regular DNN module).
Prior to DNN 4.4 was possible to add it to an existent built-in Host pages, like "SQL" or "File Manager", etc., but those pages have been turned read-only by the Core team.
You must review and save the module's setting after performing an upgrade.
Add the module to "host/admin" pages only. NEVER put it on any kind of "public" page.
Rename the default backup folder name.
Rename the default backup file names.
> Q: since the module is listed on the Module list (at Control Panel on the top), so everybody that have Edit access can add this module right ? How to protect that Admin or Host is the only role that can use Backup module ?
A: Once configured you can browse to Host / SQL and execute:
update {databaseOwner}{objectQualifier}DesktopModules
set isadmin=1
where friendlyname='Evotiva.BackupScript'
After that, the module will 'disappear'
from the Control Panel on the Top. The side effect is that you will also lose its
"Settings" menu item.
The module scripts the following database objects and their relations/bindings:
UserDefinedDataTypes, Defaults, Rules, UserDefinedFunctions, Tables, Views, StoredProcedures
The module fully supports the following data types:
"tinyint", "smallint", "int", "bigint", "decimal", "real", "float", "numeric", "money", "smallmoney", "nchar", "nvarchar", "char", "varchar", "uniqueidentifier", "datetime", "smalldatetime", "varbinary", "binary", "bit"
The module also supports all the BLOB data types:
"ntext", "text", "image"
Any database size is fully supported. The module can deal with huge database containing huge Blob data.
The module can save all the .sql and .SqlDataProvider files under
(DNN Core files)
\Providers\DataProviders\SqlDataProvider
The configured (web.config) DNN installation template (DotNetNuke.install.config by default) is also saved.
(3rd. Party modules)
\DesktopModules\<modulename>\Providers\DataProviders\SqlDataProvider
\DesktopModules\<modulename1>\<modulename2>\Providers\DataProviders\SqlDataProvider
Note: other files under other "not standard" (these) folders will not be saved.
There are some things that cannot be scripted/backup/restore, like "timestamp", "user-defined", "sql_variant" and "table" data types columns. But you probably will not have that kind of data.
The module ignores BLOB data for tables without a defined Primary Key as they would be impossible to restore. But you probably will not have a table without a PK and with BLOBs.
You can use the integrated "Table's PKs validator" to find tables in this situation.
When the module detects this problem, the generated table scripts will include this kind of comment "-- Ignoring BLOB data for table XXXX (no PK defined.)"
Please note that as the module reads and scripts your objects and data they may be changing. So, there is a possibility of inconsistent data being scripted.
You can guess the column that should be the primary key looking the result for (run from Host > SQL):
-- replace xxxxxxxxxxxxx with the table name
SELECT col.name, col.colid, col.isnullable,
typ.name
FROM syscolumns col
JOIN systypes typ on col.xtype=typ.xtype
WHERE id = OBJECT_ID('{objectQualifier}xxxxxxxxxxxxx')
Sample sql code to create some missing primary keys (run from Host > SQL):
ALTER TABLE {databaseOwner}{objectQualifier}grmRepositoryComments
ADD CONSTRAINT [PK_{objectQualifier}grmRepositoryComments]
PRIMARY KEY CLUSTERED
(
[ItemId]
) ON [PRIMARY]
GO
ALTER TABLE {databaseOwner}{objectQualifier}grmRepositoryObjects
ADD CONSTRAINT [PK_{objectQualifier}grmRepositoryObjects] PRIMARY KEY CLUSTERED
(
[ItemId]
) ON [PRIMARY]
GO
ALTER TABLE {databaseOwner}{objectQualifier}Forum_PM
ADD CONSTRAINT [PK_{objectQualifier}Forum_PM] PRIMARY KEY CLUSTERED
(
[PMID]
) ON [PRIMARY]
GO
ALTER TABLE {databaseOwner}{objectQualifier}Forum_PM_Posts
ADD CONSTRAINT [PK_{objectQualifier}Forum_PM_Posts] PRIMARY KEY CLUSTERED
(
[PMID]
) ON [PRIMARY]
GO
BackupNative module can backup your entire database "at once" (native SQL Server backup).
When using legacy Zip format: 65535 entries / 2Gb max zip file size.
When using ZIP64 format: lot of entries, 4gb max zip file size.
An upcoming version will support the new SQL Server 2005 data types: nvarchar(max), varchar(max), and varbinary(max)
The module was tested on older DNN versions like DNN 3.0.13, 3.1.x, 4.0.2, 4.0.3. and also work fine on any DNN version up to the most current ones.
Note: BackupScript 3.x (and above) does not run in DNN3.
It supports SQL Server 2000 and SQL Server 2005.
Like DNN itself, the module requires write permissions over the file system.
When configured to script the database objects, current version relays on SQL-DMO (sqldmo.dll) library or SMO assemblies (DNN4 only) to get some information from the database.
DMO library should be installed on the web server for this setting to work.
No SQLServer installed on the IIS machine is needed by the module. Only the sqldmo.dll is needed (when this feature is enabled). This dll is automatically installed with the sql server client (and of course also when installing the sql server, but the fact is that just the sql server client installed is needed.). The dll can also be installed without installing the sql client. See http://support.microsoft.com/kb/q248241/ and http://support.microsoft.com/?kbid=326613 for more information.
Disabled feature (release 2.0.2): On DNN4 you can select SMO as database objects scripting library instead of DMO. SMO library should be installed on the web server for this setting to work.
SMO does not allow partially trusted callers, thus using SMO is 100% managed code but still needs the site running on full trust level.
NOTE: You can vote to get SMO fixed (Microsoft): http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=262072
So, ONLY when configured to script the database objects, this module requires DNN (your web site) to be configured on "Full trust" mode (trust level="Full") because needs the DMO or SMO library.
This is generally set in the machine.config and is normally set this way, but this may not be true for some servers.
When scripting database objects using the DMO library, current version,
doesn’t supports a "connection string" (configured at the web.config file) written
in a SQL Server 2005 Express way (e.g. "Data
Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|Database.mdf;"
providerName="System.Data.SqlClient").
It supports Connection String for SQL Server 2000/2005.
NOTE: By default DMO is not available on SQL Server 2005 Express,
and trying to access a SQL Server 2005 db with the older (SQL Server 2000) versions
of the SQL DMO is not possible. You will need at least the "Microsoft SQL Server
2005 Backward Compatibility Components"
If you successfully installed DMO on your server, you will need to change the connection
string to something like (do not forget to include the trailing
";" character):
e.g.:
"Server=myserver;Database=mydatabase;uid=user;pwd=password;"
"Server=SERVER\SQLEXPRESS;Database=dotnetnuke;uid=johndoe;pwd=thepass;"
"Server=XXXXXX;Database=YYYYYY;Integrated Security=True;"
"Data Source=.\SQLEXPRESS;Initial Catalog=mydatabase;uid=sa;pwd=mypass;"
"Data Source=.\SQLExpress;Initial Catalog=DotNetNuke;Integrated Security=True;"
You can simply disable the "script database objects" setting and the module will work fine. See this section.
Since 1.2 version, the DMO/SMO library is no longer needed by the module to script the table's data or to perform restore operations.
Table's content scripting should work without any problem on any
ISP (*) and running your site in medium trust
level.
On demo (unregistered) mode, the module scripts three tables (EventLog, Modules and TabModules) to enable you to test this functionality at your real site BEFORE purchasing.
The restore utility is also 100% "DMO/SMO free". You should be able to restore your database objects and/or data on any ISP (*) and run your site in medium trust level
(*) YES, even at GoDaddy Shared server plan and other very restrictive ISPs!!!. See GoDaddy Configuration
We’ve tested the module at GoDaddy “Deluxe
Plan”, on DNN 3.3.5 and 4.3.5 MANUALLY INSTALLED (successfully backup the
site: table’s data + portal files)
Also we successfully restored the site (the module’s backup files) locally on a
dev. machine, following the on-line module’s manual instructions.
TIP: test the module BEFORE purchasing (it's FREE to try), and let us know any issue you may find.
Q: I’m really interested in this awesome module. How can I know if it will work on my ISP?
A: Thanks! Just download it, install it and use it. If it’s powerful FREE features works, then all the other features will work too. If it fails, please contact us to research the problem and find if it is really an ISP incompatibility issue or something misconfigured.
Q: I get this error when trying to script my database. What does it means?
---> System.Exception:
Error connecting to SQLServer (DMO) after retrying 15 times.
---> System.NullReferenceException: Object reference
not set to an instance of an object.
A: This error looks like you don't have access to the needed SQLDMO library. May be the dll is not installed or may be it's blocked to your web site. Please check with your ISP if it is possible to access the sqlsmo.dll from your web site.
In any case you can disable the objects structure scripting and backup your data (table's contents) only because doesn't need any special library
Read more about sqldmo.dll on the Requirements section.
Q: I get this error when trying to script my table's contents. What does it means?
--->
System.Data.SqlClient.SqlException: SELECT permission denied on object 'REFERENTIAL_CONSTRAINTS',
database 'master', owner 'INFORMATION_SCHEMA'.
A:
This is a known error at GoDaddy Shared server plan. The access
to your database information (which tables do you have with which structure, etc.)
is blocked at SQL Server level. In this case
you should check the "use custom schema views" setting.
Read more on the Requirements section and GoDaddy Configuration
Q: I get this error when trying to backup What does it means?
Database script generation failed.
---> System.UnauthorizedAccessException: Access to the path "C:\www\inetpub\mysite.com\backup\WORK\" is denied.
A: . It means that the ASP.NET user
(the windows user under with DNN runs, that is “NETWORK SERVICE” on IIS 6, when
not "impersonated") does not have the required read/write access on the
module’s configured folder branch (In this case, \backup and beyond). Check the
Requirements section.
You have to set read/write access (file system permissions) to the ASP.Net user
(“network service” on IIS6) for the configure backup folder branch.
If your site is hosted, it depends on the ISP (some of them provides an administrative
web console. In other cases you may have to ask them to do it for your)
If you have local access to the server this is done from the: right-click / “sharing
and security..” pop-up menu option
Q: How can I know more details about a database backup or restore operation?
A: For each database backup and
restore operation a ".log" file (same name of the backup file) is written.
There you can read the list of the performed tasks.
The same information is shown "on screen" after
a database backup or restore operation.
Q: Can I get a limited time FULL version of your module so I can fully test it on my real environment?
A: Sure, please contact us, but note that the current "free" functionality of the module is enough to fully test it.
Q: I’m interested in your module to install it on my 8 domains. Should I purchase 8 licenses?
A: Of course not. You can purchase
an enterprise license that gives you the right to install it in as many of YOUR
domains as you want.
Please note that this license is not intended for hosters
or resellers. You are not allowed to redistribute (free or not) your license.
Q: Should I really need one license for each domain on my DNN installation?
A: No, because current version backups
your full database, not individual portals. So, the backup for one domain will include
the other portal/domains too.
Currently, you will only need one license for each physical
database you use.
More than 3 or 4 portals, justifies purchasing an Enterprise
license (many portals/databases) which includes also the full source code (VS 2003
and VS 2500 solutions).
Q: Ok, I bought the module. How can I get my license?
A: With your purchase you get instant access to a time limited "enterprise" license. That is, you get instant access to all the module's features on any domain. Meanwhile, send us a mail with your full domain and main purchase information (invoice#, your name, email, etc.) and we’ll send you your definitive license string. Just paste it on the module’s Settings page. There ("Licensing Information" section) you’ll see your full domain name and a link that helps you to prepare the email. For more information see Configuration / Licensing information section.
Q: How can I know my full domain name?
A: You can get it form the module’s Settings page, "Licensing information" section.
Q: The module failed to backup my database. What’s next?
A: Please contact us and we’ll research the problem. It could be simply something misconfigured, something regarding to your web server, your ISP or something specific of your database. Every database is a word and weird things can be made inside them. We do our best considering as many cases/scenarios as we can imagine. If the problem cannot be fixed or workaround, you can get the refund.
Q: I would like to use this module
to backup an entire portal, and then restore it to a new location.
e.g. I have a portal called "myfirstportal" and it uses the database "first",
I want to back this up and then restore it to "mysecondportal" and the
database "second". Is this possible?
A: Sure, if there are no other portals inside the target database.
Q: Can I backup a particular portal (instead of all of them)?
A: If you mean "portal" as whole DNN; sure, you can do that (same as previous question). You can see restore samples (to a different site/database) on the module's documentation. If you mean "portal" as an individual "child" portal, the module currently cannot backup and restore individual portals within the database.
Q: Much of my DNN site uses XMod modules - will it back up the content and config of those too?
A: Yes, this module will "script" all the XMod tables too. Upcoming version will let you choose also which tables include/exclude. Currently all tables (all data) on the database are scripted.
Q: How should I configure the module to run at GoDaddy Shared Hosting Plan?
A: See GoDaddy Configuration
Q: Do you know where can I found instructions about how to install DNN at GoDaddy Shared Hosting Plan?
A: See GoDaddy Configuration
Q: Can I make this module work with SQL Express 2005?
A: Yes. Please check the Requirements section.
Q: Can I use your product to move a site from one ISP to another?
A: YES. You just need an already empty (or not) database created and all
your database objects and table's data can be recreated. In fact we've moved sites
from one ISP to another using BackupScript (with ISP minimal intervention, just
to create and empty db and to give rights to asp.net over the file system) and also
using BackupNative (when we have access to the native database backup files and
we can ask the ISP for restoring it).
The module can import/export its setting (implements the standard
DNN IPortable interface, from its actions menu) .
Note: You must edit and save the module settings the first time before using this
feature.
|
Module Information |
Information about your environment: module, DNN and .Net version. |
|
Current Domain |
Your web site domain (read only). An "email" link is provided. You can use it to pre-write an email to be sent for requesting a FULL license. |
|
License Status |
Your current license status and information. |
|
License key |
Place to paste the provided license information.
How to get registered: - Email us your full domain ( "Current Domain" show your full domain name and a link which helps you to prepare the email) and main purchase information (invoice#, your name, email, etc) - We’ll email you the license string. - Paste the license string on this textbox - Save your setting and re-enter the Settings page to activate the previously disabled options. |
|
Database Information |
Information about your database: location, name and version. |
|
Backup Database |
Perform the database backup operation?
|
|
Database Backup File Name |
Name of the file to be generated by the database backup operation . e.g.: mydatabase.sql |
|
Script (backup) table's data |
Extracts (backup) each table contents (as "INSERT INTO" scripts). |
|
Tables list |
Enables you to select which tables to include or exclude from the data scripting
process (create their "insert into" scripts) |
|
Script DataProviders |
Saves all the .SqlDataProvider and related files (core & 3rd. party) ** highly recommended - enables you to restore without any DNN running, no matter if DMO or SMO is available |
|
Script Database Objects |
Build the necessary scripts to recreate the database structure |
|
Script Method |
Script objects method (DMO or SMO). SMO is not valid on DNN3.
|
|
Use custom schema views |
Use custom schema views instead of the global INFORMATION_SCHEMA
views. |
|
Warn about missingPKs |
if disabled, before performing a backup the tables PKs check will not be performed (will not warn you if a table with blob data lacks of Primary Key) |
|
Create Portals Content Zip File |
Create the Zip File with the portal contents (files and folders of
all the portals at the Host)?
|
|
Portal contents backup file
|
Name of the zip file to generate with the portal contents (files and folders of the host's portals). e.g. myfiles |
|
Include web.config file |
Include the web.config file within the portal contents Zip file? |
|
Include 'Host' folder |
Include 'Host' folder (Portals\_default) within the Data Zip file? |
|
Include \bin folder |
Include \bin folder within the Data Zip file? |
|
Include Modules folder |
Include \DesktopModules folder within the portal contents Zip file? |
|
Include other folders |
Include all other folders and files within the portal contents Zip file? |
|
Exclude Folders List |
Comma separated list of relative folders to exclude from the backup (e.g.: \Portals\0\SpecialFolder,\App_Data) |
|
External Folders List |
Comma separated list of absolute folders to include in the backup (e.g.: C:\mysecurefolder\myDMXfiles,E:\otherimportanfolder).
Within the backup zip file, all will be under \_XTRNL folder. |
|
Backup folder name |
Backup folder name, relative to the web site's root folder (will be created if necessary). e.g.: backup or portals/_default/backup Since version 3.0.1, you can alternatively configure an arbitrary absolute folder (it should have the necessary access permissions. |
|
Compression Level |
Compression level (for the compressed ZIP file creation). 0 - store only to 9 - means best compression, 6 - default |
|
Zip64 format |
Configures the use of the newer Zip64 format for the generated Zip file. Note: may not be legible by some legacy tools, buit-in WinXP compression included. |
|
Zip password |
Password for the resulting Zip files (leave blank for no password). |
|
Append date/time: |
Append current date/time to the backup file name (database and portals files)? |
|
Backup file Max Count |
How many backup files do you want to keep? NOTE: 0 means keep it all (use it with care, it may fill your hard disk). |
|
Page Refresh Rate |
Page Refresh Rate for backup/restore progress information (in seconds). e.g. 7 seconds |
|
Process Priority |
Priority for the backup/restore process thread |
|
Download method |
Alternate implementations for the download links. |
|
Impersonate backup thread |
Turn it on only if you get security error messages when performing the backup. May be necessary e.g. when on your web config file this option is turned on: <identity impersonate="true"/> |
|
FTP transfer enabled |
Enable to transfer the backup file(s) via FTP to the configured FTP server. Notes: - An existing file will be overwritten. - Old files will not be purged. |
|
FTP Server |
FTP server name or IP address (e.g. ftp.myothersite.com) |
|
FTP User |
User (credentials) for the FTP server |
|
FTP Password |
Password (credentials) for the FTP server |
|
Use Passive mode |
Use passive mode data connection (otherwise will use active mode). Note that active and passive refer to the operation of the FTP server, not the client. |
|
FTP transfer enabled |
FTP transfer enabled? |
|
Remote folder |
Where to upload the files on the remote folder (e.g. backupfiles/mysitebackup). Note: you can leave this setting empty to upload to the default folder. |
|
Schedule Enabled |
Schedule Enabled? |
|
Notify Scheduled Backup to |
Email account to notify scheduled backups executions (live blank to ignore) |
|
Include download links in email? |
Checked means that direct download links will be present in the notification email. |
|
Time Lapse |
Example: "5" and select "Minutes" to run task every 5 minutes. Leave blank to disable timer for this task. |
|
Retry Frequency |
Example: "5" and select "Minutes" to retry the task every 5 minutes after a failure. Leave blank to disable retry-timer for this task. |
|
Retain Schedule History |
Example: Select "10" to keep the ten most recent schedule history rows. |
TIP: Samples for your backup folder configuration:
- mybackupfolder: "mybackupfolder" will be created under the web root and will be accessible via the module’s "Backup History Manager"
- portals/_default/mybackupfolder: "mybackupfolder" will be created under the portal Host’s root folder, will be accessible via the module’s "Backup History Manager" but also will be available from the standard DNN Host’s File Manager
On our tests, DNN was manually installed (we couldn’t get it installed on the root, but was successfully installed on a \DNN folder).
We didn't used any provided "auto install" feature.
Some installation guides:
To install DNN in the root, you can follow these instructions: http://www.mikroproje.com/DotNetNukeArticles/tabid/283/articleType/ArticleView/articleId/89/language/en-GB/Default.aspx
Backup Database: Checked
Script Database Objects: Unchecked
Script (backup) table's date: Checked
Script Method: DMO
Use custom schema views: Checked
Use custom schema views: Checked
You may need to create the \backup (configured backup folder) on the GoDaddy's Control Panel; with read, web & write permissions.
Tor its child folders: \WORK, \WORK\Blobs and \WORK\Providers; is advised set only read & write permissions.
Just configure your desired setting for the module and click on the "Perform Backup" button.
Please note that the process can take some time to complete.
It is recommended to run the built-in utilities (Stored Procedures and Table's Primary Keys validators) from time to time, before performing a backup.
TIP: Please review the companion "Quick Guide" document for a simplified backup/restore procedure.
A full backup log file is written to disk (on the configured backup folder): LOGByyyymmddhhmm_BACKUP.log
Depending on your setting will be created and compressed the following files:
e.g. if you've configured "Backup file name" is "mydatabase.sql", a "mydatabase.sql.zip" file will be generated containing:
|
DROP_ mydatabase.sql |
Contains the script for dropping all the database objects from your database. |
|
FKsINS_ mydatabase.sql |
Contains the script for generating all the foreign keys of each table. |
|
FKsDEL_ mydatabase.sql |
Contains the script for dropping all the foreign keys of each table. |
|
mydatabase_nnnnnnnnnnn.sql |
Contains the scripts to generate each database object. Many files are sequentially created to avoid a monolithic huge file. |
|
Ins_[table-name]_nnnnnnnnnnn.sql |
Contains the scripts to generate the "INSERT INTO" instructions for each table. Many files are sequentially created to avoid a monolithic huge file. |
|
\Blobs |
Also will be created a \Blobs folder containing one subfolder for each table having "blob" data (text, ntext, image columns).
For each blob value a .DAT and a .TXT files will be generated. The .DAT contains the blob data itself and the .TXT contains "metadata" with the instructions necessary for restoring the BLOB value. The structure of the TXT files are: blob_datatype;table;column;where_condition
|
|
\Providers |
When "Script DataProviders" settings is enabled, this folder will be created including all the DataProvider files needed to recreate the database schema. Under \0 are the core files and under \1 are all the 3rd. party modules DataProvider files. Under \0 are also included the "InstallTemplate" configured in the web.config file and Info.config which includes other "metadata" about the site needed for properly apply the dataprovider files. |
|
RestoreInfo.resources |
XML file containing metadata about the backup file. |
Will be created also a "mydatabase.sql.zip_BACKUP.log" ((text) file, containing information about the performed operations.
Note: you may want to exclude from the backup tables like: SiteLog, EventLog, SearchItemWordPosition, SearchItemWord, SearchWord, SeachItem, etc. (which can be very huge).
If your Web Server doesn't have the DMO or SMO library available, please uncheck the “Script database objects” setting.
When unchecking this setting, only the table's data (tables contents) will be scripted. The database objects (tables, views, stored procs, etc) creation scripts will not be generated.
BackupScript version 3.x and above: You can always save the dataprovider files in your backup and thus, be able to restore the database without the “Script database objects” setting.
Depending on your setting will be created and compressed the following files:
e.g. if your configured "Portal contents backup file name" is "myfiles", a "myfiles.zip" file will be generated containing all the actual configured to be backed up files & folders under the web root , plus a "RestoreInfo.resources" containing metadata about the backup file.
It is recommended that you (at least one time but better periodically) test recreating your web site somewhere else (e.g. locally on a test/mirror environment), performing the "Case II" restoring instructions.
It is also recommended to include the web.config files on your portal files backups.
The Restore Utility (BackupScriptRestore.aspx) includes a handy SQL query tool which
you can use in a similar way that the "Sql" feature (Host > Sql) inside
DNN.
It supports {databaseOwner} and {objectQualifier} meta-keywords too.
This tool is available when calling the restore utility in "standalone" mode (not from the Backup History page).
This tool is useful to check or quick fix things against the database (any database as long as you can specify its connection string) if you do not have access to a running DNN site.
It is specially useful to update the PortalAlias table to match the new domain name (if it has changed).
Restore Utility (BackupScriptRestore.aspx) can run in two "modes":
Backup History (Case I and Case III)
This is when the restore page is automatically displayed after selecting the restore
sources on the module's "Backup History Manager" page.
On this mode you already have a running DNN, which may be totally different to the
one you are about to restore.
Standalone (Case II)
This is when you directly write the restore URL on the web browser (e.g. http://my-web-site/backup/
BackupScriptRestore.aspx).
Usually, you should not have a running (or at least "active")
DNN on this mode.
We say that a DNN is active when their full featured web.config and/or Global.asax files are on the web site's root.
TIP: Please review the companion "Quick Guide" document for a simplified backup/restore procedure.
A full restore log file is written to disk (on the configured backup folder): LOGRyyyymmddhhmm_RESTORE.log
You can edit in advance (before restoring) the Ins_PortalAlias.sql
script file or after restoring you can issue a command like this
to set the new alias (httpalias column) value:
e.g. UPDATE {databaseOwner}{objectQualifier}portalalias
SET httpalias = 'www.mymirrorsite.com'
WHERE portalaliasid = 1
When restoring to a different domain, you will
have to update the PortalAlias table to reflect the change.
After restoring you can perform this operations to set the new alias (httpalias
column).
-- replace
www.mynewdomain.com
-- replace 1 with the right value
UPDATE {databaseOwner}{objectQualifier}portalalias
SET httpalias = 'www.mynewdomain.com'
WHERE portalaliasid = 1;
You can use the "SQL Query Tool" integrated into the Restore Utility to check & update the PortalAlias table.
Like DNN itself, this module assumes the database already created and least with one user created for accessing it (in standard or trusted mode).
Please note that the restore process may take some time to complete, depending on your data volume.
This is a "Backup History" restore (check General Information section).
From the module’s "Backup History Manager", select the
backup zip files to be restored.
You can select one or two files. If your select two, they should be of different
"kind" ("database backup" or "portal files" backup).
The Restore Utility will be launched.
Check your options (will be enabled only the valid ones) and click the "Perform
Restore" button.
The restore options are pretty understandable. May be except "Database Owner"
and "Object Qualifier" which are used only when creating the temporary
database objects used by the restore utility. You should normally leave the default
values.
When needed (e.g. at GoDaddy shared hosted plan), check also
"Use custom schema views".
The restore starts and will periodically update its status.
Please note that the restore process may take some time, depending on your data
volume.
When completed, you will see on-screen the full database restore log which is also
written to disk (e.g. "mydatabase.sql.zip_RESTORE.log")
on the same folder where the backup zip file is.
Restart the application using the provided link.
- The backup Zip files should be located on the configured backup
folder (module's settings page).
- You don't have to manually create any HISRestoreInfo.resources file.
The database connection string to be used during the restore operation is
read from the 'live' DNN site's web.config file.
- You cannot restore the database objects running on this mode (you must call the
restore utility on standalone mode).
- After a database restore you MUST restart the application using the link on this
page.
Form inside DNN, you can clear the cache and/or restart the application (browse
to Host / Setting to perform this tasks).
- If you are restoring the portal files, remember that due to a asp.net
limitation the module currently can restore ONLY the \Portals branch.
If you want to restore all the portal files, uncompress the backup and use
a FTP tool to upload the needed/wanted files or use the restore option (checkbox)
to Uncompress ALL portal files to .\WORK\Site (later you can e.g. by FTP ir ISP's
Contol Panel, move what you want/need to its real location).
This is a "Standalone" restore (check General Information section).
TIP: Please review the companion "Quick Guide" document for a simplified backup/restore procedure.
Remember that like DNN itself, this module assumes the database already created and least with one user created for accessing it (in standard or trusted mode).
Sample manual creation of the database with one user:
USE master
CREATE DATABASE mydatabase
go
EXEC sp_addlogin 'myuser', 'mypassword'
go
EXEC sp_defaultdb 'myuser', 'mydatabase'
go
USE mydatabase
EXEC sp_grantdbaccess 'myuser', 'myuser'
go
EXEC sp_addrolemember 'db_owner', 'myuser'
go
Like DNN itself, this module needs write access over the web site files and folders because it has to create/delete temporary files and folders.
We will suppose an empty web site (but already created).
You can put your backup zip files in any folder under the web root. The only requirement is that "BackupScriptRestore.aspx" should be on the same folder.
After restoring your database, you may need to change some information on the "PortalAlias" table to match your new web site name and/or virtual directory.
You can check the DNN documentation for more information about the "PortalAlias" table.
You can also perform this change in advance (before restoring) manually editing the "Ins_PortaAlias.sql" file inside the backup Zip file (more information on PortalAlias table section).
Let's say you want your backup zip files are under /backup.
Web site structure:
(WebRoot)
+--- backup
|
+--- bin
Create /bin and /backup
Upload to /bin:
all DLLs contained on the module’s install_package (Evotiva.BackupScript_xxxxx_Install.zip).
DotNetNuke.dll that matches your DNN installation version (3.x, 4.x, …)
You can extract it from the portal files backup (myfiles.zip).
Note: in fact, any DotNetNuke.dll should work (same asp.net version).
Upload to /backup :
The database backup zip file (mydatabase.sql.zip)
the backup zip files (e.g. myfiles.zip and/or mydatabase.sql.zip) When restoring to a different domain, you will have update the PortalAlias table reflect change.
All files included within "Resources.zip" (which is inside the installation
package)
(BackupScriptRestore.aspx, module.css, CreateHelperProcs.* (all the "CreateHelperProcs"
files), DropHelperProcs.SqlScript and pleaseWait.gif contained on the module’s installation
package (found within Resources.zip which is inside the installation package)
Optionally you can upload a simple web.config file to the web root
but the Restore Utility doesn’t requires any special web.config file.
Note: the restore utility can create this simple web.config file for you.
Sample minimal suggested web.config file for restoring backups:
<configuration>
<appSettings>
</appSettings>
<system.web><!-- set debugmode to false for running application -->
<compilation debug="false" />
<!-- permits errors to be displayed for remote clients -->
<customErrors mode="Off" />
<!-- page level options -->
<pages validateRequest="false" enableViewStateMac="true" />
</system.web>
</configuration>
Browse to <mysite>/backup/default.aspx
e.g. http://www.mysite.com/backup/default.aspx
The Restore Utility will be launched.
Check your options (will be enabled only the valid ones) and click the "Perform
Restore" button.
The restore options are pretty understandable. May be except "Database Owner"
and "Object Qualifier" which are used only when creating the temporary
database objects used by the restore utility and needed by the integrated SQL Query
Tool. You should set those values same as in your original web.config file.
The restore starts and will periodically update its status.
Please note that the restore process may take some time, depending on your data
volume.
When completed, you will see on-screen the full database restore log which is also
written to disk (e.g. "mydatabase.sql.zip_RESTORE.log")
on the same folder where the backup zip file is.
Use the integrated "SQL Query Tool" to check & update the PortalAlias table.
Restart the application using the provided link.
- The backup Zip file(s) to be restored should be located on the
same physical folder as this ASPX file.
- OPTIONALLY you can manually create a HISRestoreInfo.resources file (on this same
physical folder).
The database connection string to be used during the restore operation is
read form this HISRestoreInfo.resources (NOT from the original RestoreInfo.resources
within the backup ZIP file).
If the HISRestoreInfo.resources file is not found, you MUST write (on screen)
the appropriate database connection string.
- If you want to restore the database objects please disable (e.g. rename) the Global.asax
file and replace the standard DNN web.config file with a minimal one. Also may be
necessary disable (e.g. move somewhere else) all the DLLs not used by the restore
utility.
- If you are restoring both database objects and table's data is recommended to
perform the restore in two stages.
On the first one just check the 'Create objects' option and after its successful
restoration run the tool again to restore the table's data only ('Restore data'
checkbox).
- If you don't have the database objects creation scripts remember that all the
required tables must be created before the restore, otherwise it will fail
(see Case III).
- If you are restoring a database backup performed on a different
machine and/or ISP and/or domain:
+ remember that you may need to change the connection string BEFORE performing
the restore.
+ remember to change the PortalAlias table to reflect the new portal's domain
(more information on PortalAlias table section).
+ You can use the "SQL Query Tool" integrated into
the Restore Utility to check & update the PortalAlias table.
- If you are restoring the portal files, remember that due to a asp.net limitation
the module currently can restore ONLY the \Portals branch.
If you want to restore all the portal files, uncompress the backup and use
a FTP tool to upload the needed/wanted files.
You have to follow Case III.
Just unzip the "myfiles.zip" file under the web root. The \Portals branch can be uncompressed by the Restore Utility.
When restoring to a different domain, you will have to update the PortalAlias table to reflect the change. backup zip files (e.g. myfiles.zip and/or mydatabase.sql.zip)
NOTE: since BackupScript 3.x, this case is obsolete beacuse you can always restore on Case II if you included the dataprovider files in the backup ("Script DataProviders" checkbox enabled on the module's settings page). This setting will work no matter if DMO or SMO is available on the source server.
Note that only will be created the structure for tables defined in the dataproviders. Any "external" table cannot be recreated (unless you enable the "script database objects" setting).
TIP: Please review the companion "Quick Guide" document for a simplified backup/restore procedure.
This is a "Backup History" restore (check General Information section).
Case II prerequisites
You should have a complete or partial "Portal Files" backup of your source
site
(you will need at least the web.config file and the \Portals branch).
You will need the 3rd parties PAs installed on the source site
(or alternatively, their database creation scripts: \DesktopModules\<module>\Providers\DataProviders\SqlDataProvider)
Uncompress your "Portal Files" backup on your web site root.
Perform a regular DNN installation (same version than the one you want to restore
its database) using the web.config from your original (source) site.
Edit the connection string as needed.
TIP: If you have a full "Portal Files" backup, to install DNN you just need to uncompress
the \install branch on the DNN install package.
The installation will be automatically triggered, or it can be manually triggered
browsing to <site>/Install/Install.aspx?mode=Install
NOTE: It is very important keep the original web.config information, otherwise after
restoring you may loose all the passwords, etc. (MachineValidationKey, MachineDecryptionKey,
...)
Perform a regular installation of each 3rd. party module installed on the original
(source) site.
Alternatively, if you don't have those PAs, you can Browse to Host / SQL and execute
each script under \DesktopModules\<module>\Providers\DataProviders\SqlDataProvider.
At this point, you have a functional "empty" DNN site with all 3rd. party
modules needed already installed.
Install BackupScript and add it to any page (can be the home page
or whatever; because it will disappear after restoring the backup)
Configure BackupScript (module settings page) with the desired
backup folder name (where you'll upload the backup zip files). Configure the file
names to match the one to be restored (their template name).
IMPORTANT: edit & save its setting even if you will not change any of
them.
Follow the Case I steps.
|
1.1.0 |
May 2006 |
- First public release |
|
1.3.0 |
June 2006 |
- DMO library is no longer needed by the module to script the table's data. Now on demo (unregistered) mode, the module scripts three tables (EventLog, Modules and TabModules) to show you this functionality working on your real site. - DMO library is no longed needed also by the Restore Utility - Fully functional for all DNN versions (3.x, 4.x) - Performance improvements (backups up to 70% faster than the previous version) |
|
1.3.3 |
July 2006 |
- Implemented three selectable download methods for the backup zip files - improved compatibility with some hosted environments - improved support of tables with too many columns - added support for blank database password (not recommended!) |
|
2.0.1 |
August 2006 |
- Added SMO scripting objects method (DNN4 only) - log (text) files are written with each backup and restore operation - backup table's data can run on medium trust level - you can also restore any backup on medium trust level - Portal Contents Backup zip file now includes empty folders - Portal Contents Backup can be configured to exclude any folder (Exclude Folders List) - Solved "CryptoAPI cryptographic service provider (CSP) for this implementation could not be acquired" which happened on some hosting environments |
|
2.0.3 |
October 2006 |
- Temporary removed SMO scripting objects method (DNN4 only).
Waiting for an official hot fix from Microsoft for
KB913297
- Improved "friendly" messages and internal settings management. - Improved documentation
- Improved compatibility with even more restrictive hosting environments.
|
|
2.0.4 |
November 2006 |
- Avoids unzipping empty folders on some environments. - Improved support for tables with too much (and huge) columns. |
|
2.0.5 |
December 2006 |
- Improved compatibility with more ISPs (e.g. aruba.it). |
|
2.0.6 |
January 2007 |
- New settings to tweak some ISPs issues (e.g. verio). - Improved environment information on the settings page. |
|
2.1.1 |
March 2007 |
- Improved backup/restore experience (more info, simplified steps,
step ahead detection of potential common problems, and more).
|
|
2.1.2 |
March 2007 |
- Added license key textbox on the restore page. - Added test link for the connection string on the restore page. - Added test link for the license key on the restore page. |
|
2.1.3 |
May 2007 |
- Select which tables to include/exclude. e.g. may be you don’t need to backup de contents of tables like SiteLog, EventLog, SearchItemWordPosition, SearchItemWord, SearchWord, SeachItem, etc. (which also can be very huge). - Auto-detect "0" selected backup files max. count (autofix to 1) - Auto-correct folders exclude list format (should use "\") - Removed some "false positives" on the "bad procedures detection" feature |
|
2.1.5 |
August 2007 |
- Added 'quick test' and an additional hint to guess if DMO is available or not. - Added Zip64 format for the backup (Zip) files. A lot more capacity (entries and total file size). - Added new restore option to Uncompress ALL portal files to .\WORK\Site (later you can e.g. by FTP ir ISP's Contol Panel, move what you want/need to its real location) - you may have to update the connection strings on the web.config file - - Added "SQL Query Tool" integrated into the Restore Utility. Useful to check & update e.g. the PortalAlias table or whatever you want. - Added automated simple web.config file, useful when restoring in standalone mode (you don't have to manually create and upload it) - Improved compatibility for restoring empty folders that may exist within a backup zip file. - Many minor changes/enhancements . |
|
2.1.6 |
October 2007 |
- Improved restore feedback - Updated ZIP library (0.85.4 / September 9, 2007) |
|
3.0.0 |
November 2007 |
- New license key required - New "Script DataProviders" settings which enables a full restore (Case II) no matter if DMO or SMO is available on the source server (at restore time). - Improved documentation (new 'quick guide'). - When restoring, now does not stop on the first error found (if any). It keeps running and restoring as much as it can. - Many minor changes/enhancements. - New "External Folders List" setting, which enables include any absolute arbitrary folder within the portal files backup (they should have the proper access permissions). - New option to automatically FTP the backup files somewhere else. - The backup folder can now be any absolute folder. You can configure a folder outside the web site root (it should have the proper access permissions). - Improved backup and restore feedback. |
|
3.0.3 |
December 2007 |
- added support for dataprovider files not directly below \DesktopModules. e.g. DesktopModules\Bring2mind\DMX - fixed "System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection" thrown on specific portals with specific child portals configurations - new log files are written to disk (on the configured backup folder): LOGByyyymmddhhmm_BACKUP.log and LOGRyyyymmddhhmm_RESTORE.log; including the full backup and restore log (database and/or files, etc.), even when an error is thrown. |
A clean DNN33x or DNN43x install creates invalid procedures that make the database objects restore fail because they cannot be re-created.
Those stored procedures are:
- AddEvent
- DeleteEvent
- GetEvent
- GetEvents
- GetEventsByDate
- UpdateEvent
- Forum_ForumUserViewsUpdate
On a blank DNN 4.7.0 (with all the default modules installed):
- Blog_Upgrade_ForumGroupsByGroup
- Blog_Upgrade_ForumGroupsList
- Blog_Upgrade_ForumThreadsList
- Forum_AA_StatisticsSiteUpdate
- Forum_ForumUserViewsUpdate
There are two workarounds for this problem:
1) delete them from the database before performing the backup
2) delete their creation script from the generated script files.
Note: you may have to delete also their "drop proc"
script which should be before the "create proc" script .
NOTE: This can happen with any other (core or custom) module. e.g. a similar problem was identified on a "GetList" stored procedure which references an obsolete "'DisplayName" column.
You can use the built in "Stored Procedures Validator" to identify and clean those invalid procedures. Use it with case, paying special attention to each error shown by the utility (which indicates why the module thinks the procedure is invalid). Good candidates to be removed are procedures throwing 'Invalid column name' error(s).
This problem was not found on a clean DNN44 installation.
As stated on the "What cannot be scripted" section, some information cannot be scripted for tables without a primary key.
You can use the built in "Table's PK validator" to look for tables with this problem.
Some known tables with problems are (may change depending on the module's version):
- Forum_PM (used by the DNN Forum module)
- grmRepositoryComments (used by the DNN Repository module)
- grmRepositoryObjects (used by the DNN Repository module)
To workaround this problem, you can create PKs for those tables, because they should have one, and all (should) have a “unique” column like: “ [ItemID] [int] IDENTITY (1, 1) NOT NULL”
To create a primary key you can issue a command (Host / Sql) like this:
ALTER TABLE {databaseOwner}{objectQualifier}grmRepositoryComments
ADD PRIMARY KEY (ItemID)
What if this utility find tables with this problem?
You should identify which module use them; contact the module developers and ask
them how to fix the problem (which PK create).
When “impersonation” is "true" on the web.config file and the necessary permissions are not granted for the default asp.net user on the web server, Scheduled backups will not work (at least on and DNN3 and for DNN4.4.x and below) throwing a kind of "access denied" error when trying to read or write a file.
This is a known (http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=5068) DNN Core bug, which will be fixed on a upcoming core release.
More information at http://www.dotnetnuke.com/Community/ForumsDotNetNuke/tabid/795/forumid/107/threadid/47749/threadpage/11/scope/posts/Default.aspx.
Here is a limited list of features considered for upcoming releases:
Copyright © 2006-2007 – – www.evotiva.com – All rights reserved.
|
FREE Edition |
Standard Edition |
Enterprise Edition |
|
|
Private Assembly |
Yes |
Yes |
Yes |
|
VB.Net Source Code |
No |
No |
Yes |
|
Installation License |
Unlimited 'localhost' installations |
1 production DNN installation |
Unlimited |
|
Redistribution |
Not permitted |
Not permitted |
Not permitted |
EVOTIVA grants
you a non-exclusive, non-transferable right to use this module on your DotNetNuke
(DNN) installation.
One Production License is required to install and use this module on each DotNetNuke
installation. A DNN installation is defined as a single DNN database which can host
multiple portals. These portals may have their own unique web addresses, but they
are managed from a single DNN host, you must purchase additional Production License
for each extra DNN installation unless you purchase an Enterprise license which
gives you the right to install it in as many of YOUR
DNN installations
as you want.
Please note that the Enterprise License is not intended to be user by ISPs ('hosters'),
resellers, webmasters (or whatever) for their customers. You are not allowed to
redistribute (free or not) your single or enterprise license.
You are permitted to use this software for FREE on an unlimited number of machines running the local IIS instance ("localhost" domain).
Without a purchased license, you are permitted to use the software for FREE on an unlimited number of DotNetNuke installations with the limited functionality provided by the (unlicensed) software.
EVOTIVA END USER LICENSE AGREEMENT (EULA)
Please review the following license agreement before installing or
using the licensed EVOTIVA software product and/or its related materials.
Definitions: This EVOTIVA, End-User Software License Agreement ("EULA")
is a legal agreement between you (either as an individual user, corporation or single
entity) and EVOTIVA, for a product which includes computer software, and may include
associated media, printed materials, and online or electronic documentation ("SOFTWARE
PRODUCT" or "SOFTWARE"). By exercising your rights to install the
SOFTWARE PRODUCT, you agree to be bound by the terms of this EULA, including the
limitations and warranty disclaimers.
If you do NOT agree to the terms of this EULA, please return the SOFTWARE PRODUCT
and immediately destroy all copies of the SOFTWARE PRODUCT in your possession.
SOFTWARE PRODUCT LICENSE
The SOFTWARE PRODUCT is protected by copyright laws and international copyright
treaties, as well as other intellectual property laws and treaties.
1. GRANT OF NON-EXCLUSIVE LICENSE.
This is a license agreement, and NOT an agreement for sale. EVOTIVA retains ownership
of the copy of THE SOFTWARE in your possession, and all copies you may be licensed
to use. EVOTIVA retains all rights not expressly granted to you in this LICENSE.
EVOTIVA hereby grants to you, and you accept, a non-exclusive, non-transferable
license to use, copy and modify THE SOFTWARE only as authorized below.
Provided that you have accepted the terms contained herein, this EULA grants you
the following rights:
A) EVOTIVA grants you a non-exclusive, non-transferable right to use this module
on your DotNetNuke (DNN) installation.
One Production License is required to install and use this module on each DotNetNuke
installation. A DNN installation is defined as a single DNN database which can host
multiple portals. These portals may have their own unique web addresses, but they
are managed from a single DNN host, you must purchase additional Production License
for each extra DNN installation unless you purchase an Enterprise license which
gives you the right to install it in as many of YOUR
DNN installations as you want.
B) If you purchased the SOURCE CODE, you are granted to view the source code of
the SOFTWARE PRODUCT and modify it for use as described above. Under no circumstances
may the source code or products developed by using the source code be re-distributed
in any form.
C) Regardless of the type of license purchased, if the SOFTWARE PRODUCT includes
reusable software such as controls, components, plug-ins, stylesheets, etc. you
may not use any of these independently of the SOFTWARE PRODUCT.
In no case shall you rent, lease, lend, redistribute nor re-license THE SOFTWARE PRODUCT or source code to a 3rd party individual or entity, except as outlined above. In no case shall you grant further redistribution rights for THE SOFTWARE PRODUCT to the end-users of your solution.
2. DESCRIPTION OF OTHER RIGHTS AND LIMITATIONS.
Termination. Without prejudice to any other rights, EVOTIVA may terminate this EULA
if you fail to comply with the terms and conditions of this EULA. In such event,
you must destroy all copies of the SOFTWARE PRODUCT and all of its component parts,
source code, associated documentation, and related materials.
3. COPYRIGHT.
All title and copyrights in and to the SOFTWARE PRODUCT (including but not limited
to any images, photographs, animations, video, audio, music, text, and "applets"
incorporated into the SOFTWARE PRODUCT), the accompanying printed materials, and
any copies of the SOFTWARE PRODUCT are owned by EVOTIVA except for certain portions
for which EVOTIVA has obtained redistribution rights from the title or copyright
holder. The SOFTWARE PRODUCT is protected by the laws of Uruguay and international
treaty provisions. Therefore, you must treat the SOFTWARE PRODUCT like any other
copyrighted material.
4. LIMITED WARRANTY.
NO WARRANTIES. EVOTIVA expressly disclaims any warranty for the SOFTWARE PRODUCT.
The SOFTWARE PRODUCT and any related documentation is provided "as is"
without warranty of any kind, either express or implied, including, without limitation,
the implied warranties of merchantability, fitness for a particular purpose, or
non-infringement. The entire risk arising out of use or performance of the SOFTWARE
PRODUCT remains with you.
You acknowledge that the software may not
be free from defects and may not satisfy all of your needs.
5. LIMITATION OF LIABILITY.
NO LIABILITY FOR CONSEQUENTIAL DAMAGES. In no event shall EVOTIVA or its distributors
be liable for any damages whatsoever (including, without limitation, damages for
loss of business profits, business interruption, loss of business information, or
any other financial loss) arising out of the use of or inability to use this EVOTIVA
product (THE SOFTWARE PRODUCT) and related materials, even if EVOTIVA has been advised
of the possibility of such damages.
If you have any questions regarding this End User License Agreement, please email:
licensing@evotiva.com