Hello Experts,
I perform a backup with a password (quiet long), but I'm
afraid of tools that may read the password/break the file.
My question is if I place a long password would it be
more difficult tools read the passw (255 chars) or it's
hopeless?
Thanks in advance!
Konstantinos MichasUsing a password on a backup doesn't prevent other people reading your data.
It just prevents an unauthorised person using SQLServer to restore the data
and therefore may make it slightly more difficult for them to access the
data. The backup isn't encrypted so it's still possible to read the backup
media using third party tools.
In short, if the confidentiality of your data is important to you, you
probably shouldn't rely on a backup password (of any length).
David Portas
SQL Server MVP
--|||To add some to David's correct response there is a 3rd party tool called SQL
LiteSpeed that will encrypt the entire backup for you and they won't be able
to easily crack it.
Andrew J. Kelly SQL MVP
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
> Using a password on a backup doesn't prevent other people reading your
data.
> It just prevents an unauthorised person using SQLServer to restore the
data
> and therefore may make it slightly more difficult for them to access the
> data. The backup isn't encrypted so it's still possible to read the backup
> media using third party tools.
> In short, if the confidentiality of your data is important to you, you
> probably shouldn't rely on a backup password (of any length).
> --
> David Portas
> SQL Server MVP
> --
>|||Hello and thanks both for your response, 3d party tools
can read the structure of DB from bakcup file, right?
Thanks in advance?
Konstantinos
>--Original Message--
>To add some to David's correct response there is a 3rd
party tool called SQL
>LiteSpeed that will encrypt the entire backup for you
and they won't be able
>to easily crack it.
>
>--
>Andrew J. Kelly SQL MVP
>
>"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
wrote in message
>news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
people reading your[vbcol=seagreen]
>data.
SQLServer to restore the[vbcol=seagreen]
>data
them to access the[vbcol=seagreen]
possible to read the backup[vbcol=seagreen]
important to you, you[vbcol=seagreen]
length).[vbcol=seagreen]
>
>.
>|||What do you mean by that? The 3rd party tool I was referring to simply does
a backup and encrypts the resulting backup file. Are you asking if it can
then read the file later on? If so then of coarse as it would be pretty
useless to encrypt the file and not be able to restore it. But you will
need the key to do this and if memory serves me right it is 128 bit (or
higher) encryption.
Andrew J. Kelly SQL MVP
"ATHENS 2004" <anonymous@.discussions.microsoft.com> wrote in message
news:d8b101c43a8f$4f4b8460$a601280a@.phx.gbl...[vbcol=seagreen]
> Hello and thanks both for your response, 3d party tools
> can read the structure of DB from bakcup file, right?
> Thanks in advance?
> Konstantinos
>
> party tool called SQL
> and they won't be able
> wrote in message
> people reading your
> SQLServer to restore the
> them to access the
> possible to read the backup
> important to you, you
> length).|||I don't know of any tool specifically designed to read a password protected
SQL backup if that's what you mean. I was actually referring to software
that can read *any* data from backup media (for example:
http://www.intermedia.uk.com/mmpc.htm). If you can read the data file then
it's certainly possible to extract information from it. I'm pretty sure it's
also theoretically possible to hack a password-protected backup so that it
can be restored to SQLServer without the password.
David Portas
SQL Server MVP
--|||I see, thank you both answering!
>--Original Message--
>Hello and thanks both for your response, 3d party tools
>can read the structure of DB from bakcup file, right?
>Thanks in advance?
>Konstantinos
>
>party tool called SQL
>and they won't be able
>wrote in message
>people reading your
>SQLServer to restore the
>them to access the
>possible to read the backup
>important to you, you
>length).
>.
>
Showing posts with label tools. Show all posts
Showing posts with label tools. Show all posts
Thursday, March 8, 2012
Backup passw
Hello Experts,
I perform a backup with a password (quiet long), but I'm
afraid of tools that may read the password/break the file.
My question is if I place a long password would it be
more difficult tools read the passw (255 chars) or it's
hopeless?
Thanks in advance!
Konstantinos MichasUsing a password on a backup doesn't prevent other people reading your data.
It just prevents an unauthorised person using SQLServer to restore the data
and therefore may make it slightly more difficult for them to access the
data. The backup isn't encrypted so it's still possible to read the backup
media using third party tools.
In short, if the confidentiality of your data is important to you, you
probably shouldn't rely on a backup password (of any length).
--
David Portas
SQL Server MVP
--|||To add some to David's correct response there is a 3rd party tool called SQL
LiteSpeed that will encrypt the entire backup for you and they won't be able
to easily crack it.
Andrew J. Kelly SQL MVP
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
> Using a password on a backup doesn't prevent other people reading your
data.
> It just prevents an unauthorised person using SQLServer to restore the
data
> and therefore may make it slightly more difficult for them to access the
> data. The backup isn't encrypted so it's still possible to read the backup
> media using third party tools.
> In short, if the confidentiality of your data is important to you, you
> probably shouldn't rely on a backup password (of any length).
> --
> David Portas
> SQL Server MVP
> --
>|||Hello and thanks both for your response, 3d party tools
can read the structure of DB from bakcup file, right?
Thanks in advance?
Konstantinos
>--Original Message--
>To add some to David's correct response there is a 3rd
party tool called SQL
>LiteSpeed that will encrypt the entire backup for you
and they won't be able
>to easily crack it.
>
>--
>Andrew J. Kelly SQL MVP
>
>"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
wrote in message
>news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
>> Using a password on a backup doesn't prevent other
people reading your
>data.
>> It just prevents an unauthorised person using
SQLServer to restore the
>data
>> and therefore may make it slightly more difficult for
them to access the
>> data. The backup isn't encrypted so it's still
possible to read the backup
>> media using third party tools.
>> In short, if the confidentiality of your data is
important to you, you
>> probably shouldn't rely on a backup password (of any
length).
>> --
>> David Portas
>> SQL Server MVP
>> --
>>
>
>.
>|||What do you mean by that? The 3rd party tool I was referring to simply does
a backup and encrypts the resulting backup file. Are you asking if it can
then read the file later on? If so then of coarse as it would be pretty
useless to encrypt the file and not be able to restore it. But you will
need the key to do this and if memory serves me right it is 128 bit (or
higher) encryption.
Andrew J. Kelly SQL MVP
"ATHENS 2004" <anonymous@.discussions.microsoft.com> wrote in message
news:d8b101c43a8f$4f4b8460$a601280a@.phx.gbl...
> Hello and thanks both for your response, 3d party tools
> can read the structure of DB from bakcup file, right?
> Thanks in advance?
> Konstantinos
> >--Original Message--
> >To add some to David's correct response there is a 3rd
> party tool called SQL
> >LiteSpeed that will encrypt the entire backup for you
> and they won't be able
> >to easily crack it.
> >
> >
> >
> >--
> >Andrew J. Kelly SQL MVP
> >
> >
> >"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
> wrote in message
> >news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
> >> Using a password on a backup doesn't prevent other
> people reading your
> >data.
> >> It just prevents an unauthorised person using
> SQLServer to restore the
> >data
> >> and therefore may make it slightly more difficult for
> them to access the
> >> data. The backup isn't encrypted so it's still
> possible to read the backup
> >> media using third party tools.
> >>
> >> In short, if the confidentiality of your data is
> important to you, you
> >> probably shouldn't rely on a backup password (of any
> length).
> >>
> >> --
> >> David Portas
> >> SQL Server MVP
> >> --
> >>
> >>
> >
> >
> >.
> >|||I don't know of any tool specifically designed to read a password protected
SQL backup if that's what you mean. I was actually referring to software
that can read *any* data from backup media (for example:
http://www.intermedia.uk.com/mmpc.htm). If you can read the data file then
it's certainly possible to extract information from it. I'm pretty sure it's
also theoretically possible to hack a password-protected backup so that it
can be restored to SQLServer without the password.
--
David Portas
SQL Server MVP
--|||I see, thank you both answering!
>--Original Message--
>Hello and thanks both for your response, 3d party tools
>can read the structure of DB from bakcup file, right?
>Thanks in advance?
>Konstantinos
>>--Original Message--
>>To add some to David's correct response there is a 3rd
>party tool called SQL
>>LiteSpeed that will encrypt the entire backup for you
>and they won't be able
>>to easily crack it.
>>
>>--
>>Andrew J. Kelly SQL MVP
>>
>>"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
>wrote in message
>>news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
>> Using a password on a backup doesn't prevent other
>people reading your
>>data.
>> It just prevents an unauthorised person using
>SQLServer to restore the
>>data
>> and therefore may make it slightly more difficult for
>them to access the
>> data. The backup isn't encrypted so it's still
>possible to read the backup
>> media using third party tools.
>> In short, if the confidentiality of your data is
>important to you, you
>> probably shouldn't rely on a backup password (of any
>length).
>> --
>> David Portas
>> SQL Server MVP
>> --
>>
>>
>>.
>.
>
I perform a backup with a password (quiet long), but I'm
afraid of tools that may read the password/break the file.
My question is if I place a long password would it be
more difficult tools read the passw (255 chars) or it's
hopeless?
Thanks in advance!
Konstantinos MichasUsing a password on a backup doesn't prevent other people reading your data.
It just prevents an unauthorised person using SQLServer to restore the data
and therefore may make it slightly more difficult for them to access the
data. The backup isn't encrypted so it's still possible to read the backup
media using third party tools.
In short, if the confidentiality of your data is important to you, you
probably shouldn't rely on a backup password (of any length).
--
David Portas
SQL Server MVP
--|||To add some to David's correct response there is a 3rd party tool called SQL
LiteSpeed that will encrypt the entire backup for you and they won't be able
to easily crack it.
Andrew J. Kelly SQL MVP
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
> Using a password on a backup doesn't prevent other people reading your
data.
> It just prevents an unauthorised person using SQLServer to restore the
data
> and therefore may make it slightly more difficult for them to access the
> data. The backup isn't encrypted so it's still possible to read the backup
> media using third party tools.
> In short, if the confidentiality of your data is important to you, you
> probably shouldn't rely on a backup password (of any length).
> --
> David Portas
> SQL Server MVP
> --
>|||Hello and thanks both for your response, 3d party tools
can read the structure of DB from bakcup file, right?
Thanks in advance?
Konstantinos
>--Original Message--
>To add some to David's correct response there is a 3rd
party tool called SQL
>LiteSpeed that will encrypt the entire backup for you
and they won't be able
>to easily crack it.
>
>--
>Andrew J. Kelly SQL MVP
>
>"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
wrote in message
>news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
>> Using a password on a backup doesn't prevent other
people reading your
>data.
>> It just prevents an unauthorised person using
SQLServer to restore the
>data
>> and therefore may make it slightly more difficult for
them to access the
>> data. The backup isn't encrypted so it's still
possible to read the backup
>> media using third party tools.
>> In short, if the confidentiality of your data is
important to you, you
>> probably shouldn't rely on a backup password (of any
length).
>> --
>> David Portas
>> SQL Server MVP
>> --
>>
>
>.
>|||What do you mean by that? The 3rd party tool I was referring to simply does
a backup and encrypts the resulting backup file. Are you asking if it can
then read the file later on? If so then of coarse as it would be pretty
useless to encrypt the file and not be able to restore it. But you will
need the key to do this and if memory serves me right it is 128 bit (or
higher) encryption.
Andrew J. Kelly SQL MVP
"ATHENS 2004" <anonymous@.discussions.microsoft.com> wrote in message
news:d8b101c43a8f$4f4b8460$a601280a@.phx.gbl...
> Hello and thanks both for your response, 3d party tools
> can read the structure of DB from bakcup file, right?
> Thanks in advance?
> Konstantinos
> >--Original Message--
> >To add some to David's correct response there is a 3rd
> party tool called SQL
> >LiteSpeed that will encrypt the entire backup for you
> and they won't be able
> >to easily crack it.
> >
> >
> >
> >--
> >Andrew J. Kelly SQL MVP
> >
> >
> >"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
> wrote in message
> >news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
> >> Using a password on a backup doesn't prevent other
> people reading your
> >data.
> >> It just prevents an unauthorised person using
> SQLServer to restore the
> >data
> >> and therefore may make it slightly more difficult for
> them to access the
> >> data. The backup isn't encrypted so it's still
> possible to read the backup
> >> media using third party tools.
> >>
> >> In short, if the confidentiality of your data is
> important to you, you
> >> probably shouldn't rely on a backup password (of any
> length).
> >>
> >> --
> >> David Portas
> >> SQL Server MVP
> >> --
> >>
> >>
> >
> >
> >.
> >|||I don't know of any tool specifically designed to read a password protected
SQL backup if that's what you mean. I was actually referring to software
that can read *any* data from backup media (for example:
http://www.intermedia.uk.com/mmpc.htm). If you can read the data file then
it's certainly possible to extract information from it. I'm pretty sure it's
also theoretically possible to hack a password-protected backup so that it
can be restored to SQLServer without the password.
--
David Portas
SQL Server MVP
--|||I see, thank you both answering!
>--Original Message--
>Hello and thanks both for your response, 3d party tools
>can read the structure of DB from bakcup file, right?
>Thanks in advance?
>Konstantinos
>>--Original Message--
>>To add some to David's correct response there is a 3rd
>party tool called SQL
>>LiteSpeed that will encrypt the entire backup for you
>and they won't be able
>>to easily crack it.
>>
>>--
>>Andrew J. Kelly SQL MVP
>>
>>"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
>wrote in message
>>news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
>> Using a password on a backup doesn't prevent other
>people reading your
>>data.
>> It just prevents an unauthorised person using
>SQLServer to restore the
>>data
>> and therefore may make it slightly more difficult for
>them to access the
>> data. The backup isn't encrypted so it's still
>possible to read the backup
>> media using third party tools.
>> In short, if the confidentiality of your data is
>important to you, you
>> probably shouldn't rely on a backup password (of any
>length).
>> --
>> David Portas
>> SQL Server MVP
>> --
>>
>>
>>.
>.
>
Backup passw
Hello Experts,
I perform a backup with a password (quiet long), but I'm
afraid of tools that may read the password/break the file.
My question is if I place a long password would it be
more difficult tools read the passw (255 chars) or it's
hopeless?
Thanks in advance!
Konstantinos Michas
Using a password on a backup doesn't prevent other people reading your data.
It just prevents an unauthorised person using SQLServer to restore the data
and therefore may make it slightly more difficult for them to access the
data. The backup isn't encrypted so it's still possible to read the backup
media using third party tools.
In short, if the confidentiality of your data is important to you, you
probably shouldn't rely on a backup password (of any length).
David Portas
SQL Server MVP
|||To add some to David's correct response there is a 3rd party tool called SQL
LiteSpeed that will encrypt the entire backup for you and they won't be able
to easily crack it.
Andrew J. Kelly SQL MVP
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
> Using a password on a backup doesn't prevent other people reading your
data.
> It just prevents an unauthorised person using SQLServer to restore the
data
> and therefore may make it slightly more difficult for them to access the
> data. The backup isn't encrypted so it's still possible to read the backup
> media using third party tools.
> In short, if the confidentiality of your data is important to you, you
> probably shouldn't rely on a backup password (of any length).
> --
> David Portas
> SQL Server MVP
> --
>
|||Hello and thanks both for your response, 3d party tools
can read the structure of DB from bakcup file, right?
Thanks in advance?
Konstantinos
>--Original Message--
>To add some to David's correct response there is a 3rd
party tool called SQL
>LiteSpeed that will encrypt the entire backup for you
and they won't be able
>to easily crack it.
>
>--
>Andrew J. Kelly SQL MVP
>
>"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
wrote in message[vbcol=seagreen]
>news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
people reading your[vbcol=seagreen]
>data.
SQLServer to restore the[vbcol=seagreen]
>data
them to access the[vbcol=seagreen]
possible to read the backup[vbcol=seagreen]
important to you, you[vbcol=seagreen]
length).
>
>.
>
|||What do you mean by that? The 3rd party tool I was referring to simply does
a backup and encrypts the resulting backup file. Are you asking if it can
then read the file later on? If so then of coarse as it would be pretty
useless to encrypt the file and not be able to restore it. But you will
need the key to do this and if memory serves me right it is 128 bit (or
higher) encryption.
Andrew J. Kelly SQL MVP
"ATHENS 2004" <anonymous@.discussions.microsoft.com> wrote in message
news:d8b101c43a8f$4f4b8460$a601280a@.phx.gbl...[vbcol=seagreen]
> Hello and thanks both for your response, 3d party tools
> can read the structure of DB from bakcup file, right?
> Thanks in advance?
> Konstantinos
> party tool called SQL
> and they won't be able
> wrote in message
> people reading your
> SQLServer to restore the
> them to access the
> possible to read the backup
> important to you, you
> length).
|||I don't know of any tool specifically designed to read a password protected
SQL backup if that's what you mean. I was actually referring to software
that can read *any* data from backup media (for example:
http://www.intermedia.uk.com/mmpc.htm). If you can read the data file then
it's certainly possible to extract information from it. I'm pretty sure it's
also theoretically possible to hack a password-protected backup so that it
can be restored to SQLServer without the password.
David Portas
SQL Server MVP
|||I see, thank you both answering!
>--Original Message--
>Hello and thanks both for your response, 3d party tools
>can read the structure of DB from bakcup file, right?
>Thanks in advance?
>Konstantinos
>party tool called SQL
>and they won't be able
>wrote in message
>people reading your
>SQLServer to restore the
>them to access the
>possible to read the backup
>important to you, you
>length).
>.
>
I perform a backup with a password (quiet long), but I'm
afraid of tools that may read the password/break the file.
My question is if I place a long password would it be
more difficult tools read the passw (255 chars) or it's
hopeless?
Thanks in advance!
Konstantinos Michas
Using a password on a backup doesn't prevent other people reading your data.
It just prevents an unauthorised person using SQLServer to restore the data
and therefore may make it slightly more difficult for them to access the
data. The backup isn't encrypted so it's still possible to read the backup
media using third party tools.
In short, if the confidentiality of your data is important to you, you
probably shouldn't rely on a backup password (of any length).
David Portas
SQL Server MVP
|||To add some to David's correct response there is a 3rd party tool called SQL
LiteSpeed that will encrypt the entire backup for you and they won't be able
to easily crack it.
Andrew J. Kelly SQL MVP
"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org> wrote in message
news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
> Using a password on a backup doesn't prevent other people reading your
data.
> It just prevents an unauthorised person using SQLServer to restore the
data
> and therefore may make it slightly more difficult for them to access the
> data. The backup isn't encrypted so it's still possible to read the backup
> media using third party tools.
> In short, if the confidentiality of your data is important to you, you
> probably shouldn't rely on a backup password (of any length).
> --
> David Portas
> SQL Server MVP
> --
>
|||Hello and thanks both for your response, 3d party tools
can read the structure of DB from bakcup file, right?
Thanks in advance?
Konstantinos
>--Original Message--
>To add some to David's correct response there is a 3rd
party tool called SQL
>LiteSpeed that will encrypt the entire backup for you
and they won't be able
>to easily crack it.
>
>--
>Andrew J. Kelly SQL MVP
>
>"David Portas" <REMOVE_BEFORE_REPLYING_dportas@.acm.org>
wrote in message[vbcol=seagreen]
>news:JuWdnZVgqIWAtTvdRVn-uw@.giganews.com...
people reading your[vbcol=seagreen]
>data.
SQLServer to restore the[vbcol=seagreen]
>data
them to access the[vbcol=seagreen]
possible to read the backup[vbcol=seagreen]
important to you, you[vbcol=seagreen]
length).
>
>.
>
|||What do you mean by that? The 3rd party tool I was referring to simply does
a backup and encrypts the resulting backup file. Are you asking if it can
then read the file later on? If so then of coarse as it would be pretty
useless to encrypt the file and not be able to restore it. But you will
need the key to do this and if memory serves me right it is 128 bit (or
higher) encryption.
Andrew J. Kelly SQL MVP
"ATHENS 2004" <anonymous@.discussions.microsoft.com> wrote in message
news:d8b101c43a8f$4f4b8460$a601280a@.phx.gbl...[vbcol=seagreen]
> Hello and thanks both for your response, 3d party tools
> can read the structure of DB from bakcup file, right?
> Thanks in advance?
> Konstantinos
> party tool called SQL
> and they won't be able
> wrote in message
> people reading your
> SQLServer to restore the
> them to access the
> possible to read the backup
> important to you, you
> length).
|||I don't know of any tool specifically designed to read a password protected
SQL backup if that's what you mean. I was actually referring to software
that can read *any* data from backup media (for example:
http://www.intermedia.uk.com/mmpc.htm). If you can read the data file then
it's certainly possible to extract information from it. I'm pretty sure it's
also theoretically possible to hack a password-protected backup so that it
can be restored to SQLServer without the password.
David Portas
SQL Server MVP
|||I see, thank you both answering!
>--Original Message--
>Hello and thanks both for your response, 3d party tools
>can read the structure of DB from bakcup file, right?
>Thanks in advance?
>Konstantinos
>party tool called SQL
>and they won't be able
>wrote in message
>people reading your
>SQLServer to restore the
>them to access the
>possible to read the backup
>important to you, you
>length).
>.
>
Friday, February 24, 2012
backup MSDE
Hello,
i'm trying to make a backup for my MSDE database with that .bat file:
cd C:\Program Files\Microsoft SQL Server\80\Tools\Binn
BACKUP DATABASE db1 TO DISK = 'C:\MSDE-backup\db1.bak'
pause
I get the following error:
The filename, directory name, or a volume label is incorrect
What i know for sure is that db1 exist and C:\MSDE-backup\db1.bak exist too.
When we download sql2kdesksp3.exe, did we have everything to perform BACKUP and RESTORE or where is my mistake ?
MSDE database work properly and i can connect to it. I have sysadmin permission.
Thanks.don't you have to run this using osql?
cs|||it is not what I did ? where is my mistake ?|||you have to run the BACKUP command through osql.exe I don't see that in your batch file.
cs|||is it possible you give me the correct batch file because i don't understand. thanks.|||In your first line, you CD (change directory).
In your second line you are trying to call some program called "backup", which doesn't exist.
You need to write:
osql.exe <other stuff here
which will call osql.exe and pass in the appropriate parameters.
Cheers
Ken|||That does not work:
cd C:\Program Files\Microsoft SQL Server\80\Tools\Binn\
osql.exe
BACKUP DATABASE db1 TO DISK = 'C:\MSDE-backup\db1.bak'
pause|||What Ken is saying is that the BACKUP command is not a program or DOS command. It's a SQL command. As such, you have to have a way to send that command to SQL Server. OSQL.EXE is a program that accepts a SQL command as one of its parameters.
Try this...
cd C:\Program Files\Microsoft SQL Server\80\Tools\Binn\
osql.exe -q "BACKUP DATABASE db1 TO DISK = 'C:\MSDE-backup\db1.bak'" -E
pause|||I had the good and fast response of another forum:
cd C:\Program Files\Microsoft SQL Server\80\Tools\Binn\
osql -S servername -E -Q "BACKUP DATABASE db1 TO DISK = 'C:\MSDE-backup\db1.bak'"
pause
thanks anyway|||I first tried m33b example with no luck then ronba's AND IT WORKED.
Thanks for saving my sleepless night ;)...<|||Can this .bat file also be modified to restore??|||osql is a command-line utility for executing most any SQL command. As such, you should be able to build a RESTORE command that would do what you want.|||Thanks, but is it not just a matter of replacing the word BACKUP with RESTORE and moving the paths a little around ?
But I see there is special options in the command...|||take a look at that link below, that perhaps will help you:
http://support.microsoft.com/default.aspx?scid=kb;en-us;325003|||There are quite a few options on the SQL restore command. Commands for replacing an existing database, moving the file to a new location, etc. You'd definitly want to find the documentation on the RESTORE command to get it to do exactly what you want.
Thursday, February 16, 2012
backup log
I'm trying to export my database to a server (WebMatrixHosting.net) ...
So I'm using the DTS - Import/Export Wizard of MSSQL Tools ...
It generates the script ok, but when the copy starts I receive an error: Failed to copy objects from SQL Server to SQL Server ...
Looking at the log file I found out the error: BACKUP LOG permission denied in database 'database_name' ...
So I set Backup log permission using the Enterprise Manager to my database. But the error remains.
What's wrong and how to fix it?
ThanksCont.
So I'm using the DTS - Import/Export Wizard of MSSQL Tools ...
It generates the script ok, but when the copy starts I receive an error: Failed to copy objects from SQL Server to SQL Server ...
Looking at the log file I found out the error: BACKUP LOG permission denied in database 'database_name' ...
So I set Backup log permission using the Enterprise Manager to my database. But the error remains.
What's wrong and how to fix it?
ThanksCont.
I set Backup log permission for my database locally, not the database_name that is returning an error. (stupid isn't?)
I need the command line to set permission for the backup log for database_name (using the query analyser), because I'm unable to use Enterprise Manager.
Thanks
Subscribe to:
Posts (Atom)