Backups - The ugly truth

[Gerhard]

W2K cannot do scheduled backups. Even the slew of ini and batch files that
are being passed around basically do not work. You have to know what your
media label is, but that is virtually impossible when you cycle tapes with
off-site storage. Therefore - no backup.

Is this a giveback to Veritas?
Gerhard

 

[Pegasus \(MVP\)]

W2K cannot do scheduled backups. Even the slew of ini and batch files that
are being passed around basically do not work. You have to know what your
media label is, but that is virtually impossible when you cycle tapes with
off-site storage. Therefore - no backup.

Is this a giveback to Veritas?
Gerhard

Mmh. Some strange things in this post.
- Win2000 (you probably mean "ntbackup.exe") can certainly
do scheduled backups.
- ntbackup does not use any .ini files.
- ntbackup can work with or without batch files.
- If your batch file does not work then it is not written correctly.
- ntbackup can work even if the media lable is not known.

On the other hand, ntbackup is not the easiest program to
use. It requires a good knowledge of the Removable Storage
Manager to do what you want it to do.

 

[Lanwench [MVP - Exchange]]

W2K cannot do scheduled backups. Even the slew of ini and batch
files that are being passed around basically do not work. You have
to know what your media label is, but that is virtually impossible
when you cycle tapes with off-site storage. Therefore - no backup.

Is this a giveback to Veritas?
Gerhard

Well, NTBackup was originally written by Veritas.

I do scheduled backups of W2k all the time with NTBackup and batch files.
Sounds like your config may have some problems - if so, post details.

 

[Enkidu]

W2K cannot do scheduled backups. Even the slew of ini and batch files that
are being passed around basically do not work. You have to know what your
media label is, but that is virtually impossible when you cycle tapes with
off-site storage. Therefore - no backup.

All my backup are scheduled jobs using NTBackup.

If you don't like the media thing use paper labels and the /um flag.

Cheers,

Cliff

 

[David H. Lipman]

And Veritas is soon to be owned by Symantec.

http://news.zdnet.com/2100-1009_22-5493289.html

Dave




"Lanwench [MVP - Exchange]" <[email protected]>
wrote in message | Gerhard wrote:
| > W2K cannot do scheduled backups. Even the slew of ini and batch
| > files that are being passed around basically do not work. You have
| > to know what your media label is, but that is virtually impossible
| > when you cycle tapes with off-site storage. Therefore - no backup.
| >
| > Is this a giveback to Veritas?
| > Gerhard
|
| Well, NTBackup was originally written by Veritas.
|
| I do scheduled backups of W2k all the time with NTBackup and batch files.
| Sounds like your config may have some problems - if so, post details.
|
|

 

[Lanwench [MVP - Exchange]]

And Veritas is soon to be owned by Symantec.

http://news.zdnet.com/2100-1009_22-5493289.html

Dave

Yes, alas

As someone wrote in another group recently -
"Symantec: Where good software goes to die."

I don't think it's quite as dire as if Veritas had been bought by CA,
however.

"Lanwench [MVP - Exchange]"

Well, NTBackup was originally written by Veritas.

I do scheduled backups of W2k all the time with NTBackup and batch
files. Sounds like your config may have some problems - if so, post
details.

 

[David H. Lipman]

No Symantec CEO or management has [yet] been charged with crimes by the US Security and
Exchange Commission (SEC) unlike Computer Associates. Symantec has a corporate culture that
cares more about their stock price than the support of "Mom and Dad" or Joe down the street
who use their software.

I have to profess that my Enterprise backup solution is CA Arcserve 11.1.

Dave



"Lanwench [MVP - Exchange]" <[email protected]>
wrote in message | Yes, alas
|
| As someone wrote in another group recently -
| "Symantec: Where good software goes to die."
|
| I don't think it's quite as dire as if Veritas had been bought by CA,
| however.

 

[Gerhard]

Sorry, I was out of the country for a few days and then the holidays, hence
the late reply.

Obviously my message was written out of frustration with not being able to
do scheduled backups with NTBackup on W2K. This worked beautifully, and was
a no-brainer with NT4.
With W2K they fail one way or another, wrong media, tape not initialized,
whatever. Main thing is they fail. No problem scheduling them, but the
backup fails, never happens.

They may not be called .ini, but there are multiple configuration files.
Lots of time and money has been spent trying to resolve this problem
(chargeable MS Support calls), the end result is always the same, the backup
fail with some rms quirk within a matter of days. So I guess the MS support
people do not know how to write those batch files either.

We are now doing manual backups, less frequently, obviously. It is so bad
that my Admin would rather downgrade servers to NT4 if they have to be
backed up nightly. But that is no answer of course.

Is there a book out on scheduling NTBackup on W2K? Would appreciate any
cites on the web as well. Thanks,

Gerhard

 

[Enkidu]

There are numerous scripts around that will backup Windows 2000
regularly without problmes. The crucial trick is to *write a batch
file that works* and then schedule that batch file.

http://support.microsoft.com/default.aspx?scid=kb;en-us;239892

There are some excellent links at this site, as well as the specific
ones linked to here.

http://www.jsiinc.com/sube/tip2100/rh2148.htm

http://www.jsiinc.com/sube/tip2200/rh2265.htm

Please not that the last one uses the /UM flag which you claimed was
not working. I think that that was because you had not provided the
mandatory /p flag. (necessary with /um)

I had scheduled backups running like clockwork on a number of 2000
machines, for more than two years. I know it works. I also know that
it took me a while to set it up - maybe a month for 24 machines, but I
was also doing other stuff at the time.

Cheers,

Cliff

 

[Gerhard]

Thanks a lot for the links. I'll give it another try, we too have other
things going on here like mainframe migrations. Luckily that data is in SQL
server and SQL server backs up just fine.

So, there may be 5 or 6 data servers right now where backup has been scaled
back to a manual weekly because the scheduled backups don't work.

I think the problem is that I want to append the dailies, until the weekly
cycle has been completed and then initialize the tape again. As I said,
this was not hard to do with NTBackup under NT4.
Gerhard

 

[Enkidu]

OK, I hope it works for you. Basically, I think the two secrets are
the /um flag and writing a little script to do the backup and
scheduling that and not using NT Backup Scheduler.

It IS possible to run successful backups using the above techniques. I
don't think that it is impossible to do what you want to do.

I have your munged email address and may be able to send you my script
which I *know* works! <grin>

Cheers,

Cliff

 

[Gerhard]

Ok, I see what the problem is, the /um switch does not allow you to append.
It simply overwrites the tape. This would be excellent to initialize the
tape. Our normal backup sequence is as follows:

Tue - append a full backup to the existing tape
Wed - initialize a new tape with an incremental backup
Th,Fri, Mon - append incremental backups to existing tape

This is accomplished by scheduling 3 different batch files accordingly,
bakful.bat, bakinit.bat and bakincr.bat. Backups run some time after
midnight every night except Sat and Sun.
Tapes get changed once a week, on Tuesdays and are sent to off-site storage.
Old tapes are returned from storage at that time.

From what I can tell, you have to know the name of the tape to append to it.
So this would have to be written when the tape is initialized.with the /um
switch. There may be other gotchas. I may get this to work, but I'm not
sure yet. Lots of people have tried with no success.

I think it works for you because you appear to change tapes daily, then you
can use one batch file with the /um switch everyday.
Gerhard

 

[Enkidu]

Ah, yes, so it does! You are correct, I always use one tape per
backups. That's not so nice! It probably means that you will have to
determine the guid somehow (which you mentioned waaaay back at the
beginning, as I recall)

You may find it easier (and save money in the long term), to use a
competitive product such as this:

http://www.abuse.net/relay.html

(Example only - I've never tried it)

I still believe ntbackup can do it, but interfacing with "rsm" is not
fun, as you've no doubt found out!

Cheers,

Cliff

 

[Gerhard]

Well, I found something here, which might just work.

http://www.winnetmag.com/Articles/Index.cfm?ArticleID=25961

Particularly interesting is the link on page two to Listing 1. I think it
might just work. You'll notice that this guy is rotating the tapes on a
weekly basis also. I'll let you know how this goes, thanks for your help so
far, Cliff,

Gerhard

 

[Leythos]

Ok, I see what the problem is, the /um switch does not allow you to append.
It simply overwrites the tape. This would be excellent to initialize the
tape. Our normal backup sequence is as follows:

Tue - append a full backup to the existing tape
Wed - initialize a new tape with an incremental backup
Th,Fri, Mon - append incremental backups to existing tape

Why would you not do a full backup every day?

Incremental backups are such a PITA, if your tape will hold an entire
day, what's preventing you from just doing a full backup?

I run full backups ONLY, never incremental, and I've been doing this for
more than 10 years, it's never failed me.

 

[Gerhard]

Yeah, some of those full backups run for over 8 hrs with the verify option
on, I can handle that once a week. But daily?
Also, it is virtually impossible to find the daily work in full backups,
very easy with incremental backups.
Let's face it, backups are mostly used to get files back that people
accidentally delete, not to restore entire machines.
Gerhard

 

[Pegasus \(MVP\)]

When designing a backup schedule, a decision must be
made about the worst case data loss that a business is
prepared to wear. In many cases that loss must be limited
to one working day. This implies that tapes ***must***
be exchanged daily, and that the most recent tape ***must***
be stored somewhere off-site.

Appending data to an existing backup tape (which is what
you do) has, in my opinion, some serious drawbacks:
- In case of fire, theft or electrical damage, the whole
backup medium will be lost, resulting in a massive loss
of data.
- The ability to read later backup sets depends on the
quality of the early backup sets. If the Monday backup
set has a flaw then you will not be able to read the
Thursday backup set.

For these reasons I think that backup tapes should be
exchanged daily. The cost of maintaining 10 or 20 tapes
is miniscule if you use 4mm DAT tapes.

 

[Pegasus \(MVP\)]

If your main use of backup/restore is to retrieve files that
people delete accidentally then you should schedule a
secondary backup to a hard disk, using xcopy.exe and
five folders (Mon, Tue, Wed) etc. This makes file recovery
a breeze! And remember: Hard disks are cheap!

Yeah, some of those full backups run for over 8 hrs with the verify option
on, I can handle that once a week. But daily?
Also, it is virtually impossible to find the daily work in full backups,
very easy with incremental backups.
Let's face it, backups are mostly used to get files back that people
accidentally delete, not to restore entire machines.
Gerhard

 

[Leythos]

Yeah, some of those full backups run for over 8 hrs with the verify option
on, I can handle that once a week. But daily?
Also, it is virtually impossible to find the daily work in full backups,
very easy with incremental backups.
Let's face it, backups are mostly used to get files back that people
accidentally delete, not to restore entire machines.
Gerhard

If I were in your place I would still run the FULL backup, but I would
also setup a online-backup disk volume where you can backup files based
on the need.

I do this for SQL Servers - setup a daily backup, copy the current days
backup to tape from the backup file (the one on the server) and then
delete any SQL backups older than X days - all from a script in the SQL
server.

I also have a number of backups that do NT Backups from workstations to
folders on the server so that I can catch work that is not possible to
run across a share.

Someone mentioned doing daily incremental backups to a on-line storage
unit, and I agree. I would never stop doing the FULL Backup, but I would
also setup the on-line backups (file to disk), even using XCOPY if
needed.

You don't need to do a full verify if you check the tapes every couple
weeks, that might help your backup time. Some backup applications let
you "test" at the end of a scheduled backup, just to make sure the tape
is readable, it's a good way to save time as long as you test the
backups once a week/month.

 

[Enkidu]

I'll add my vote to the "full backup" lot. Also, I *don't* verify
tapes but do do periodic tests of backups. When I have verified tapes,
I don't recall a failure. Do you actually get many?

Cheers,

Cliff

Yeah, some of those full backups run for over 8 hrs with the verify option
on, I can handle that once a week. But daily?
Also, it is virtually impossible to find the daily work in full backups,
very easy with incremental backups.
Let's face it, backups are mostly used to get files back that people
accidentally delete, not to restore entire machines.
Gerhard