Local servers are being backed up using a standard BACKUP DATABASE command. Remote - using T-SQL scripts (in permanent Beta). To use the standard backup for the servers on the same network, specify a UNC path (like \\myserver\temp\) for the Temporary folder field, so both the program and SQL Server can access it.
When installed locally (on the same machine where SQL server is), SQLBackupAndFTP backs up databases using a standard BACKUP DATABASE command. For each database you get a single *.bak file that you can restore using a standard RESTORE DATABASE command.
SQLBackupAndFTP can use a standard BACKUP DATABASE command for the servers on the same network as long as both the SQL server and SQLBackupAndFTP have access to the same temporary folder. To use this feature, specify a UNC path (like \\myserver\temp\) for the Temporary folder field in advanced settings.
If you get permission errors - you need make sure that both SQL server instance account and SQLBackupAndFTP account have read/write rights to that temporary network folder. SQL server instance often runs under "Local System" account that does not have access to the network - you'd need to run it under the account that does have access to that network folder (to change go to service properties > Log On tab) As far as SQLBackupAndFTP access - it is simpler if it is running under your personal account (in Advanced settings set "Run scheduled jobs as" to your personal account)
For remote or hosted SQL Server instances you can not use the BACKUP DATABASE command, since this command would create a *.bak file somewhere on the network local to that SQL server. And you/the client generally do not have access to that folder so getting the backups file to you local PC would be problematic. Thus, in the case of remote SQL server instances (where you can connect to these instances using SQL Management Studio) - SQLBackupAndFTP backs up databases using scripting ("remote backup"). You get one or several *.sql files with CREATE, INSERT T-SQL statements that recreate database.
Remote backup feature is in permanent unsupported Beta because of the complexity of the task. There's no harm of damaging the existing database during backup, but we can not guarantee your restore 100%. You should try the restore for yourself. Use Remote feature only on your own risk and only if other methods are not possible. Note that SQL Server 2000 is not supported for remote backup, all other versions are supported. See below for specific DB objects.
You can discuss remote backups on forum.
|SQL objects & features||Supported|
|Database creation with its properties (collate, compatibility, ANSI padding, ANSI warnings, arithabort, autoclose, auto create statistics, auto shrink, auto update statistics, set cursore close on commit, set cursor default, concat null yields nulls, numeric round abort, quoted identifier, recursive triggers, broker, auto update statistics async, date correlation optimization, trustworthy, allow snapshot isolation, parametrization, readonly, recovery, page verify, db changing)|
|Database tables structure (tables with columns, their datatypes, identities, unique constraints, collation, persisted, not for replication, allow nulls, computed columns and computing expressions)|
|Foreign keys and relations|
|Database stored procedures|
|Database user functions|
|User defined data types|
|Users to roles mapping|
|Database xml entities|
At the very basic level most of the hosters have their own web-based tools for automating SQL server database backups
Only some of the web hosts support connecting to a database from the client computer (using SQL Management Studio or SQLBackupAndFTP). You can use SQLBackupAndFTP scripting only on the sites that support it.
|Web site hoster||Control Panel Tool for DB Backup||Script backup supported|
|Webhost For ASP.NET|
|Database Mart LLC|
|Seek Dot Net|
The hosts in the list below do not have Windows or SQL Server support
Copyright © 2017 Pranas.NETBack to Top