Database Change Log

Is there any way to see what jobs and or changes have been
made to a database. Not the data itself, but things like
indexes, statistics, DB settings, or outside/automated
jobs? I know I can run a trace to see real-time actions,
but I'm interested to see what may have happened overnight
or yesterday. Any help would be greatly appreciated.
Thank you,
Heidi
Some stuff are logged in the errolog file. You can also configure each SQL Server message to say
whether it will go to the errorlog file. However, DBCC DBREINDEX, for instance, doesn't return any
messages. You can check the Agent log, but that will not catch of someone does it from outside
Agent. Depending on your situation, your only option can be Profiler, or some audit tool reading the
transaction loge (see my links page about log reader tools).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"hdsjunk" <anonymous@.discussions.microsoft.com> wrote in message
news:0d3801c49c0d$a14666b0$a301280a@.phx.gbl...
> Is there any way to see what jobs and or changes have been
> made to a database. Not the data itself, but things like
> indexes, statistics, DB settings, or outside/automated
> jobs? I know I can run a trace to see real-time actions,
> but I'm interested to see what may have happened overnight
> or yesterday. Any help would be greatly appreciated.
> Thank you,
> Heidi

Database Change Log

Is there any way to see what jobs and or changes have been
made to a database. Not the data itself, but things like
indexes, statistics, DB settings, or outside/automated
jobs? I know I can run a trace to see real-time actions,
but I'm interested to see what may have happened overnight
or yesterday. Any help would be greatly appreciated.
Thank you,
Heidi
Some stuff are logged in the errolog file. You can also configure each SQL Server message to say
whether it will go to the errorlog file. However, DBCC DBREINDEX, for instance, doesn't return any
messages. You can check the Agent log, but that will not catch of someone does it from outside
Agent. Depending on your situation, your only option can be Profiler, or some audit tool reading the
transaction loge (see my links page about log reader tools).
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"hdsjunk" <anonymous@.discussions.microsoft.com> wrote in message
news:0d3801c49c0d$a14666b0$a301280a@.phx.gbl...
> Is there any way to see what jobs and or changes have been
> made to a database. Not the data itself, but things like
> indexes, statistics, DB settings, or outside/automated
> jobs? I know I can run a trace to see real-time actions,
> but I'm interested to see what may have happened overnight
> or yesterday. Any help would be greatly appreciated.
> Thank you,
> Heidi
sql

Database Change Log

Is there any way to see what jobs and or changes have been
made to a database. Not the data itself, but things like
indexes, statistics, DB settings, or outside/automated
jobs? I know I can run a trace to see real-time actions,
but I'm interested to see what may have happened overnight
or yesterday. Any help would be greatly appreciated.
Thank you,
HeidiSome stuff are logged in the errolog file. You can also configure each SQL Server message to say
whether it will go to the errorlog file. However, DBCC DBREINDEX, for instance, doesn't return any
messages. You can check the Agent log, but that will not catch of someone does it from outside
Agent. Depending on your situation, your only option can be Profiler, or some audit tool reading the
transaction loge (see my links page about log reader tools).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"hdsjunk" <anonymous@.discussions.microsoft.com> wrote in message
news:0d3801c49c0d$a14666b0$a301280a@.phx.gbl...
> Is there any way to see what jobs and or changes have been
> made to a database. Not the data itself, but things like
> indexes, statistics, DB settings, or outside/automated
> jobs? I know I can run a trace to see real-time actions,
> but I'm interested to see what may have happened overnight
> or yesterday. Any help would be greatly appreciated.
> Thank you,
> Heidi

Database Backup And Transaction Log - SQL Server 2000

I would like to find the cleanest way to do a backup and not have to backup
the log.
I have a number of DTS jobs that run as batch - loads data into SQL Server.
I know for fact that at a certain time after the batch, no one is in the
database and no jobs are running that affect the database of system
databases. I was thinking of just executing a CHECKPOINT to force any
completed records to disc, backing up the database, and then truncating the
log. Is this the correct order? I became when I saw an article that
did a backup, then checkpoint and then truncate log - in that condition the
backup would never cover the CHECKPOINTED data.
Any suggestions would be helpful. Database has full recovery mode.You will have to backup the log - or take the risk of going with the Simple
recovery model.
If you like, you can backup the log just prior to the start of the DTS jobs.
This will ensure that you have as much space as possible during the DTS run.
If your packages load a lot of data, you can backup the log more frequently
during the run than you would at other times. After the DTS run is done,
that would be a good time to schedule your full backup.
Another thing you may want to consider is to switch your recovery model to
Bulk-logged during the running of the DTS package(s).
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
.
"MG" <MG@.discussions.microsoft.com> wrote in message
news:5A388DAD-5C6A-414C-946E-DEBA3922A769@.microsoft.com...
I would like to find the cleanest way to do a backup and not have to backup
the log.
I have a number of DTS jobs that run as batch - loads data into SQL Server.
I know for fact that at a certain time after the batch, no one is in the
database and no jobs are running that affect the database of system
databases. I was thinking of just executing a CHECKPOINT to force any
completed records to disc, backing up the database, and then truncating the
log. Is this the correct order? I became when I saw an article that
did a backup, then checkpoint and then truncate log - in that condition the
backup would never cover the CHECKPOINTED data.
Any suggestions would be helpful. Database has full recovery mode.|||
When you backup the database and the log then you will be able to shrink the
log file. If you do not backup the log then you cannot shrink therefore the
log file could get very big. I have a feeling you already know that.
"MG" <MG@.discussions.microsoft.com> wrote in message
news:5A388DAD-5C6A-414C-946E-DEBA3922A769@.microsoft.com...
>I would like to find the cleanest way to do a backup and not have to backup
> the log.
> I have a number of DTS jobs that run as batch - loads data into SQL
> Server.
> I know for fact that at a certain time after the batch, no one is in the
> database and no jobs are running that affect the database of system
> databases. I was thinking of just executing a CHECKPOINT to force any
> completed records to disc, backing up the database, and then truncating
> the
> log. Is this the correct order? I became when I saw an article
> that
> did a backup, then checkpoint and then truncate log - in that condition
> the
> backup would never cover the CHECKPOINTED data.
> Any suggestions would be helpful. Database has full recovery mode.|||Tom, Thanks for the info but I am not sure why my concept would not work.
Simply CHECKPOINT the trans log to get what is left in the trans log to the
mdf, truncate the log, then do a database backup (without backingup the tran
s
log). Why would this not work or be affective?
"Tom Moreau" wrote:

> You will have to backup the log - or take the risk of going with the Simpl
e
> recovery model.
> If you like, you can backup the log just prior to the start of the DTS job
s.
> This will ensure that you have as much space as possible during the DTS ru
n.
> If your packages load a lot of data, you can backup the log more frequentl
y
> during the run than you would at other times. After the DTS run is done,
> that would be a good time to schedule your full backup.
> Another thing you may want to consider is to switch your recovery model to
> Bulk-logged during the running of the DTS package(s).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> ..
> "MG" <MG@.discussions.microsoft.com> wrote in message
> news:5A388DAD-5C6A-414C-946E-DEBA3922A769@.microsoft.com...
> I would like to find the cleanest way to do a backup and not have to backu
p
> the log.
> I have a number of DTS jobs that run as batch - loads data into SQL Server
.
> I know for fact that at a certain time after the batch, no one is in the
> database and no jobs are running that affect the database of system
> databases. I was thinking of just executing a CHECKPOINT to force any
> completed records to disc, backing up the database, and then truncating th
e
> log. Is this the correct order? I became when I saw an article th
at
> did a backup, then checkpoint and then truncate log - in that condition th
e
> backup would never cover the CHECKPOINTED data.
> Any suggestions would be helpful. Database has full recovery mode.
>|||Executing the CHECKPOINT command will not in any way affect what will be inc
luded on your backups.
(SQL Server will do an internal CHECKPOINT with the backup execution anyhow,
but that is beside the
point.) Backup database will include all the data in a consistent state. Wha
t haven't been committed
will be restored when you do RESTORE DATABASE.
Also, "truncating the log" isn't considered good practice. Either you do reg
ular log backups, and
the log file will be emptied each time you do a log backup. By truncating th
e log, you break that
chain of log backups. Or, you don't do log backups, and all you have to do i
s to have the database
in simple recovery mode.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"MG" <MG@.discussions.microsoft.com> wrote in message
news:94AD791B-2749-4B4E-BCF6-82A32073D8A0@.microsoft.com...
> Tom, Thanks for the info but I am not sure why my concept would not work.
> Simply CHECKPOINT the trans log to get what is left in the trans log to th
e
> mdf, truncate the log, then do a database backup (without backingup the tr
ans
> log). Why would this not work or be affective?
> "Tom Moreau" wrote:
>|||Tibor,
Thanks for clearing that up. I did not know that when a backup occurs that
SQL does a checkpoint. Now it all fits. Is the Checkpoint done with the
database backup or the trans log backup?
"Tibor Karaszi" wrote:

> Executing the CHECKPOINT command will not in any way affect what will be i
ncluded on your backups.
> (SQL Server will do an internal CHECKPOINT with the backup execution anyho
w, but that is beside the
> point.) Backup database will include all the data in a consistent state. W
hat haven't been committed
> will be restored when you do RESTORE DATABASE.
> Also, "truncating the log" isn't considered good practice. Either you do r
egular log backups, and
> the log file will be emptied each time you do a log backup. By truncating
the log, you break that
> chain of log backups. Or, you don't do log backups, and all you have to do
is to have the database
> in simple recovery mode.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "MG" <MG@.discussions.microsoft.com> wrote in message
> news:94AD791B-2749-4B4E-BCF6-82A32073D8A0@.microsoft.com...
>
>|||I know for sure it is done with a database backup. Whether it is performed w
ith a log backup, I
don't know, but to me it doesn't matter as all I need to know is that the re
levant log records are
recorded in the backup media. :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"MG" <MG@.discussions.microsoft.com> wrote in message
news:6D13A79A-51F0-4C33-95C2-C992B0ADE61E@.microsoft.com...
> Tibor,
> Thanks for clearing that up. I did not know that when a backup occurs that
> SQL does a checkpoint. Now it all fits. Is the Checkpoint done with the
> database backup or the trans log backup?
> "Tibor Karaszi" wrote:
>|||Tibor,
I agree. thanks
"Tibor Karaszi" wrote:

> I know for sure it is done with a database backup. Whether it is performed
with a log backup, I
> don't know, but to me it doesn't matter as all I need to know is that the
relevant log records are
> recorded in the backup media. :-)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "MG" <MG@.discussions.microsoft.com> wrote in message
> news:6D13A79A-51F0-4C33-95C2-C992B0ADE61E@.microsoft.com...
>
>sql

Database Backup

Hi All,
We have SQL Server 2000. There were daily backup jobs scheduled and the file
size has grown very big 159 GB. How can we move this. Is there any way to
break this file and move. if we take fresh backup and delete this file will
there be any effect on the database. Backup and data are in the same drive.
Thank you in Advance.Kris
WINRAR,WINZIP to compress them?
"Kris" <Kris@.discussions.microsoft.com> wrote in message
news:561A8D62-B50E-4808-AA10-A63300829165@.microsoft.com...
> Hi All,
> We have SQL Server 2000. There were daily backup jobs scheduled and the
> file
> size has grown very big 159 GB. How can we move this. Is there any way to
> break this file and move. if we take fresh backup and delete this file
> will
> there be any effect on the database. Backup and data are in the same
> drive.
> Thank you in Advance.|||Hi Kris,
You can do a fresh backup without appending to that "big" file and if the
backup is OK (test by restoring) you can delete the 159 GB File. No,
removing an old backup has no effect on the database itself [unless you
lose the database and you desperately need that backup ]
Nathan H. Omukwenyi
"Kris" <Kris@.discussions.microsoft.com> wrote in message
news:561A8D62-B50E-4808-AA10-A63300829165@.microsoft.com...
> Hi All,
> We have SQL Server 2000. There were daily backup jobs scheduled and the
> file
> size has grown very big 159 GB. How can we move this. Is there any way to
> break this file and move. if we take fresh backup and delete this file
> will
> there be any effect on the database. Backup and data are in the same
> drive.
> Thank you in Advance.|||Hi Nathan,
At present i do not have any disk space in this drive where SQL is also
there can i do the backup in other drive will there be any problem. The
previous administrator should't have taken daily backup in the same drive.
Now i am just sorting out this issue. Should i take the backup of all the
databses and master then delete this will there be any critical issues. Any
precautions during this process or did i miss any thing else to do backup.
Thank you once again
"Nathan H. Omukwenyi" wrote:

> Hi Kris,
> You can do a fresh backup without appending to that "big" file and if the
> backup is OK (test by restoring) you can delete the 159 GB File. No,
> removing an old backup has no effect on the database itself [unless y
ou
> lose the database and you desperately need that backup ]
> Nathan H. Omukwenyi
> "Kris" <Kris@.discussions.microsoft.com> wrote in message
> news:561A8D62-B50E-4808-AA10-A63300829165@.microsoft.com...
>
>|||Best way is to backup all your databases except tempdb to another drive.
There will be no problem for SQL-Server. make sure you make a full back-up
But before you delete the old backup files why don't you put them on a tape
"Kris" wrote:
[vbcol=seagreen]
> Hi Nathan,
> At present i do not have any disk space in this drive where SQL is also
> there can i do the backup in other drive will there be any problem. The
> previous administrator should't have taken daily backup in the same drive.
> Now i am just sorting out this issue. Should i take the backup of all the
> databses and master then delete this will there be any critical issues. An
y
> precautions during this process or did i miss any thing else to do backup.
> Thank you once again
>
> "Nathan H. Omukwenyi" wrote:
>|||Right now take a backup on shared drive.
Then delete the 159gb backup file on your drive.
In future do not put backup data on the same drive, or copy backup
daily to tape from drive.
This is required because if disk will fail you will lose both data and
backup.
One more thing do not append backup on same file. In stead keep backup
policy to have different file for each backup and maintain 2-3 days
backup on drive and delete old backup.
In tape we keep backup of last 7 days, every sunday backup of last four
week and a bakcup of last month. This is the policy which we follows.
Regards
Amish Shah|||Zekske
Actually there is no tape device with this server the previous admin person
just created a folder in the SQL Server and scheduled backup jobs in the
same place where data is stored daily.
Now i have paused all backup scheduled jobs. The left out space now is 350
MB will it crash and we are working on a solution. How we can move this to
other server which has more space but it is SUN.
Just working on.. any advise , Thank you once again guys.
"Zekske" wrote:
[vbcol=seagreen]
> Best way is to backup all your databases except tempdb to another drive.
> There will be no problem for SQL-Server. make sure you make a full back-up
> But before you delete the old backup files why don't you put them on a tap
e
> "Kris" wrote:
>|||Amish
At present we do not have such a big disk space. And we do not have tape
drive attached. Prior to this it was backedup in the same drive. We have Sun
unix systems which has good disk space and also backup tape drives we are
aksing our unix guys. Do you know any way we can move or copy this files.
Thank you..
"amish" wrote:

> Right now take a backup on shared drive.
> Then delete the 159gb backup file on your drive.
> In future do not put backup data on the same drive, or copy backup
> daily to tape from drive.
> This is required because if disk will fail you will lose both data and
> backup.
> One more thing do not append backup on same file. In stead keep backup
> policy to have different file for each backup and maintain 2-3 days
> backup on drive and delete old backup.
> In tape we keep backup of last 7 days, every sunday backup of last four
> week and a bakcup of last month. This is the policy which we follows.
> Regards
> Amish Shah
>|||"Kris" <Kris@.discussions.microsoft.com> wrote in message
news:2A7AC679-2081-44D1-966A-A70395C2124C@.microsoft.com...
> Amish
> At present we do not have such a big disk space. And we do not have tape
> drive attached. Prior to this it was backedup in the same drive. We have
Sun
> unix systems which has good disk space and also backup tape drives we are
> aksing our unix guys. Do you know any way we can move or copy this files.
>
If you can run a version of Samba on the SUN system, you can create a shared
drive and backup to that.
I would do what others suggested. Make a full backup to the shared drive
and then delete the 159gb drive.
I would also suggest taht you setup the backups to go to a DIFFERENT file
each time (and then deleting the oldest files).
For example, 7 scripts, one for each day of the week that backups to
\\remoteSunshare\Monday, Tuesday, etc.
Or use the maintenance wizard and setup on a daily (or however often) one to
back up and keep N copies around.
[vbcol=seagreen]
> Thank you..
> "amish" wrote:
>|||Dear Greg & All
Thank you once again, I shall do as suggested.
Keep up the good work
Regards
"Greg D. Moore (Strider)" wrote:

> "Kris" <Kris@.discussions.microsoft.com> wrote in message
> news:2A7AC679-2081-44D1-966A-A70395C2124C@.microsoft.com...
> Sun
> If you can run a version of Samba on the SUN system, you can create a shar
ed
> drive and backup to that.
> I would do what others suggested. Make a full backup to the shared drive
> and then delete the 159gb drive.
> I would also suggest taht you setup the backups to go to a DIFFERENT file
> each time (and then deleting the oldest files).
> For example, 7 scripts, one for each day of the week that backups to
> \\remoteSunshare\Monday, Tuesday, etc.
> Or use the maintenance wizard and setup on a daily (or however often) one
to
> back up and keep N copies around.
>
>
>

Database Backup

Hi All,
We have SQL Server 2000. There were daily backup jobs scheduled and the file
size has grown very big 159 GB. How can we move this. Is there any way to
break this file and move. if we take fresh backup and delete this file will
there be any effect on the database. Backup and data are in the same drive.
Thank you in Advance.Kris
WINRAR,WINZIP to compress them?
"Kris" <Kris@.discussions.microsoft.com> wrote in message
news:561A8D62-B50E-4808-AA10-A63300829165@.microsoft.com...
> Hi All,
> We have SQL Server 2000. There were daily backup jobs scheduled and the
> file
> size has grown very big 159 GB. How can we move this. Is there any way to
> break this file and move. if we take fresh backup and delete this file
> will
> there be any effect on the database. Backup and data are in the same
> drive.
> Thank you in Advance.|||Hi Kris,
You can do a fresh backup without appending to that "big" file and if the
backup is OK (test by restoring) you can delete the 159 GB File. No,
removing an old backup has no effect on the database itself [unless you
lose the database and you desperately need that backup :)]
Nathan H. Omukwenyi
"Kris" <Kris@.discussions.microsoft.com> wrote in message
news:561A8D62-B50E-4808-AA10-A63300829165@.microsoft.com...
> Hi All,
> We have SQL Server 2000. There were daily backup jobs scheduled and the
> file
> size has grown very big 159 GB. How can we move this. Is there any way to
> break this file and move. if we take fresh backup and delete this file
> will
> there be any effect on the database. Backup and data are in the same
> drive.
> Thank you in Advance.|||Hi Nathan,
At present i do not have any disk space in this drive where SQL is also
there can i do the backup in other drive will there be any problem. The
previous administrator should't have taken daily backup in the same drive.
Now i am just sorting out this issue. Should i take the backup of all the
databses and master then delete this will there be any critical issues. Any
precautions during this process or did i miss any thing else to do backup.
Thank you once again
"Nathan H. Omukwenyi" wrote:
> Hi Kris,
> You can do a fresh backup without appending to that "big" file and if the
> backup is OK (test by restoring) you can delete the 159 GB File. No,
> removing an old backup has no effect on the database itself [unless you
> lose the database and you desperately need that backup :)]
> Nathan H. Omukwenyi
> "Kris" <Kris@.discussions.microsoft.com> wrote in message
> news:561A8D62-B50E-4808-AA10-A63300829165@.microsoft.com...
> > Hi All,
> > We have SQL Server 2000. There were daily backup jobs scheduled and the
> > file
> > size has grown very big 159 GB. How can we move this. Is there any way to
> > break this file and move. if we take fresh backup and delete this file
> > will
> > there be any effect on the database. Backup and data are in the same
> > drive.
> >
> > Thank you in Advance.
>
>|||Best way is to backup all your databases except tempdb to another drive.
There will be no problem for SQL-Server. make sure you make a full back-up
But before you delete the old backup files why don't you put them on a tape
"Kris" wrote:
> Hi Nathan,
> At present i do not have any disk space in this drive where SQL is also
> there can i do the backup in other drive will there be any problem. The
> previous administrator should't have taken daily backup in the same drive.
> Now i am just sorting out this issue. Should i take the backup of all the
> databses and master then delete this will there be any critical issues. Any
> precautions during this process or did i miss any thing else to do backup.
> Thank you once again
>
> "Nathan H. Omukwenyi" wrote:
> > Hi Kris,
> >
> > You can do a fresh backup without appending to that "big" file and if the
> > backup is OK (test by restoring) you can delete the 159 GB File. No,
> > removing an old backup has no effect on the database itself [unless you
> > lose the database and you desperately need that backup :)]
> >
> > Nathan H. Omukwenyi
> >
> > "Kris" <Kris@.discussions.microsoft.com> wrote in message
> > news:561A8D62-B50E-4808-AA10-A63300829165@.microsoft.com...
> > > Hi All,
> > > We have SQL Server 2000. There were daily backup jobs scheduled and the
> > > file
> > > size has grown very big 159 GB. How can we move this. Is there any way to
> > > break this file and move. if we take fresh backup and delete this file
> > > will
> > > there be any effect on the database. Backup and data are in the same
> > > drive.
> > >
> > > Thank you in Advance.
> >
> >
> >|||Right now take a backup on shared drive.
Then delete the 159gb backup file on your drive.
In future do not put backup data on the same drive, or copy backup
daily to tape from drive.
This is required because if disk will fail you will lose both data and
backup.
One more thing do not append backup on same file. In stead keep backup
policy to have different file for each backup and maintain 2-3 days
backup on drive and delete old backup.
In tape we keep backup of last 7 days, every sunday backup of last four
week and a bakcup of last month. This is the policy which we follows.
Regards
Amish Shah|||Zekske
Actually there is no tape device with this server the previous admin person
just created a folder in the SQL Server and scheduled backup jobs in the
same place where data is stored daily.
Now i have paused all backup scheduled jobs. The left out space now is 350
MB will it crash and we are working on a solution. How we can move this to
other server which has more space but it is SUN.
Just working on.. any advise , Thank you once again guys.
"Zekske" wrote:
> Best way is to backup all your databases except tempdb to another drive.
> There will be no problem for SQL-Server. make sure you make a full back-up
> But before you delete the old backup files why don't you put them on a tape
> "Kris" wrote:
> > Hi Nathan,
> > At present i do not have any disk space in this drive where SQL is also
> > there can i do the backup in other drive will there be any problem. The
> > previous administrator should't have taken daily backup in the same drive.
> > Now i am just sorting out this issue. Should i take the backup of all the
> > databses and master then delete this will there be any critical issues. Any
> > precautions during this process or did i miss any thing else to do backup.
> >
> > Thank you once again
> >
> >
> > "Nathan H. Omukwenyi" wrote:
> >
> > > Hi Kris,
> > >
> > > You can do a fresh backup without appending to that "big" file and if the
> > > backup is OK (test by restoring) you can delete the 159 GB File. No,
> > > removing an old backup has no effect on the database itself [unless you
> > > lose the database and you desperately need that backup :)]
> > >
> > > Nathan H. Omukwenyi
> > >
> > > "Kris" <Kris@.discussions.microsoft.com> wrote in message
> > > news:561A8D62-B50E-4808-AA10-A63300829165@.microsoft.com...
> > > > Hi All,
> > > > We have SQL Server 2000. There were daily backup jobs scheduled and the
> > > > file
> > > > size has grown very big 159 GB. How can we move this. Is there any way to
> > > > break this file and move. if we take fresh backup and delete this file
> > > > will
> > > > there be any effect on the database. Backup and data are in the same
> > > > drive.
> > > >
> > > > Thank you in Advance.
> > >
> > >
> > >|||Amish
At present we do not have such a big disk space. And we do not have tape
drive attached. Prior to this it was backedup in the same drive. We have Sun
unix systems which has good disk space and also backup tape drives we are
aksing our unix guys. Do you know any way we can move or copy this files.
Thank you..
"amish" wrote:
> Right now take a backup on shared drive.
> Then delete the 159gb backup file on your drive.
> In future do not put backup data on the same drive, or copy backup
> daily to tape from drive.
> This is required because if disk will fail you will lose both data and
> backup.
> One more thing do not append backup on same file. In stead keep backup
> policy to have different file for each backup and maintain 2-3 days
> backup on drive and delete old backup.
> In tape we keep backup of last 7 days, every sunday backup of last four
> week and a bakcup of last month. This is the policy which we follows.
> Regards
> Amish Shah
>|||"Kris" <Kris@.discussions.microsoft.com> wrote in message
news:2A7AC679-2081-44D1-966A-A70395C2124C@.microsoft.com...
> Amish
> At present we do not have such a big disk space. And we do not have tape
> drive attached. Prior to this it was backedup in the same drive. We have
Sun
> unix systems which has good disk space and also backup tape drives we are
> aksing our unix guys. Do you know any way we can move or copy this files.
>
If you can run a version of Samba on the SUN system, you can create a shared
drive and backup to that.
I would do what others suggested. Make a full backup to the shared drive
and then delete the 159gb drive.
I would also suggest taht you setup the backups to go to a DIFFERENT file
each time (and then deleting the oldest files).
For example, 7 scripts, one for each day of the week that backups to
\\remoteSunshare\Monday, Tuesday, etc.
Or use the maintenance wizard and setup on a daily (or however often) one to
back up and keep N copies around.
> Thank you..
> "amish" wrote:
> > Right now take a backup on shared drive.
> > Then delete the 159gb backup file on your drive.
> >
> > In future do not put backup data on the same drive, or copy backup
> > daily to tape from drive.
> > This is required because if disk will fail you will lose both data and
> > backup.
> >
> > One more thing do not append backup on same file. In stead keep backup
> > policy to have different file for each backup and maintain 2-3 days
> > backup on drive and delete old backup.
> >
> > In tape we keep backup of last 7 days, every sunday backup of last four
> > week and a bakcup of last month. This is the policy which we follows.
> >
> > Regards
> > Amish Shah
> >
> >|||Dear Greg & All
Thank you once again, I shall do as suggested.
Keep up the good work
Regards
"Greg D. Moore (Strider)" wrote:
> "Kris" <Kris@.discussions.microsoft.com> wrote in message
> news:2A7AC679-2081-44D1-966A-A70395C2124C@.microsoft.com...
> > Amish
> > At present we do not have such a big disk space. And we do not have tape
> > drive attached. Prior to this it was backedup in the same drive. We have
> Sun
> > unix systems which has good disk space and also backup tape drives we are
> > aksing our unix guys. Do you know any way we can move or copy this files.
> >
> If you can run a version of Samba on the SUN system, you can create a shared
> drive and backup to that.
> I would do what others suggested. Make a full backup to the shared drive
> and then delete the 159gb drive.
> I would also suggest taht you setup the backups to go to a DIFFERENT file
> each time (and then deleting the oldest files).
> For example, 7 scripts, one for each day of the week that backups to
> \\remoteSunshare\Monday, Tuesday, etc.
> Or use the maintenance wizard and setup on a daily (or however often) one to
> back up and keep N copies around.
>
> > Thank you..
> >
> > "amish" wrote:
> >
> > > Right now take a backup on shared drive.
> > > Then delete the 159gb backup file on your drive.
> > >
> > > In future do not put backup data on the same drive, or copy backup
> > > daily to tape from drive.
> > > This is required because if disk will fail you will lose both data and
> > > backup.
> > >
> > > One more thing do not append backup on same file. In stead keep backup
> > > policy to have different file for each backup and maintain 2-3 days
> > > backup on drive and delete old backup.
> > >
> > > In tape we keep backup of last 7 days, every sunday backup of last four
> > > week and a bakcup of last month. This is the policy which we follows.
> > >
> > > Regards
> > > Amish Shah
> > >
> > >
>
>