Re: Strang behavior of Backup-Agent 1.0
- From: nmm <Mircea.Malarski@xxxxxxxxxxxxx>
- Date: Sat, 18 Feb 2006 15:30:11 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
thanks for comment.
The batches are not wrong I think:
all databasefiles are located in dats\ and logs\ (with exactly 3 exceptions:
alllog.dat, msglog.dat, lastlog.dat)
They have only extension *.dat or *.log.
So while backupmode is ON, all these files are in backup-mode.
After switching backup mode off, I copy only files that are not affected by the
PSQL engine (excluded via the commandline-option
/EXCLUDE:C:\PVSW\PBA\bin\ohnedats.txt and the content of ohnedats.txt (which is
given)).
so I think, that Bill's answer will do.
Regards
M. Malarski
Leonard schrieb:
This posting has been simmering in the back of my head for ... it
looks like two weeks now.
First it appears from the batch file that you start backup mode, make
a backup, stop backup mode then make another copy of the data ON TOP
OF the backup that was just made thus wiping out the good backup.
Second, even if I didn't figure out the paths correctly on the first
point, you should not make a backup, particularly with a plain OS file
copy while the data files are not in backup mode. It can can cause
file locking issues with the database engine.
Leonard
On Sun, 05 Feb 2006 10:16:53 -0600, "Bill Bach"
<goldstar@xxxxxxxxxxxxx> wrote:
The Backup Agent is simply using the "Continuous Operations Mode" of
the database. When the ENDBU is received by the engine, the engine
confirms that all files will start the roll-in process (wherein all
changes are rolled out of the delta files into the live files again).
The problem is that this process is ALSO running in tandem with a live
system. While the changes are being rolled back to the live files, new
changes may be recorded at the Delta file -- making the process take
longer. In fact, this roll-in process can easily take in excess of
minutes and even hours in some very busy systems. (Indeed, I've seen
cases of heavily-written files that NEVER can catch up!)
Because of this, the PVBACKUP -OFF cannot be tied to the completion of
the roll-in process, and the only way to ensure that the roll-in is
complete is to wait until all deltas disappear.
Having said that, there are two solutions:
1) Exclude the Delta files from your last XCOPY. This is MUCH easier.
BTW, you may also wish to experiment with XXCOPY or ROBOCOPY -- two
XCOPY replacements that are much more powerful, and that only copy
files that have been changed. These tools can complete the copy job
much faster, with less wear & tear on the HD.
2) Add code in the batch file to loop on the delta files. Something
like:
:Loop
SLEEP 10
IF EXIST *.^^^^^^ GOTO Loop
Note that you must have the SLEEP command in your search path. Also,
note that since the ^ is an escape character for DOS, you must double
it. You can see this if you try a simple "DIR *.^^^" command, which
doesn't work.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach@xxxxxxxxxxxxxxxxxxxx
http://www.goldstarsoftware.com
*** Sydney: Pervasive.SQL Service & Support Class - 02/27/06 ***
*** Chicago: Pervasive.SQL Service & Support Class - 03/27/06 ***
nmm wrote:
Hallo Btrivieans!
we observed an odd behavior of Backup-Agent (may be we do something
wrong?)
Its on a Windows 2003-Server, running Pervasive SQL 8.6 und
Backupagent 1.0.
We run a Batch like the following (via taskmanager, every day at
22:00 o clock)
1 if not exist C:\PVSW\PBA\bin\ohnedats.txt goto error
2 C:\PVSW\PBA\bin\pvbackup.exe -on
3 xcopy f:\projekt\dats\*.dat g:\backup\projekt\dats\ /E /V /Y /R
4 xcopy f:\projekt\logs\*.log g:\backup\projekt\logs\ /E /V /Y /R
5 xcopy f:\projekt\*.dat g:\backup\projekt\ /V /Y /R
6 C:\PVSW\PBA\bin\pvbackup.exe -off
7 xcopy f:\projekt\*.* g:\backup\projekt\
/EXCLUDE:C:\PVSW\PBA\bin\ohnedats.txt /E /V /Y /R 8 :error
ohnedats.txt contains:
--------schnipp-------------
\dats\
alllog.dat
msglog.dat
lastlog.dat
\logs\
--------schnapp-------------
Usually this works fine, but sometimes (no systematic recognizable)
the xcopy in line 7 still finds *.^^^-files. This is strange,
because the "pvbackup.exe -off" is logged as completes sucessfully.
It looks like, that the command "pvbackup.exe -off" returns too
early (before compeeting its job).
We helped ourselfs by inserting some delay (using somthing like
"ping -n 1 -w 60000 1.1.1.1" = waite 60 Sec) after lines 2 and 7, but
this is not satisfactory.
Does anyone know, why pvbackup returns so early or if one can tell it
not to return befor finishing?
Any comment will be wellcome!
Best reagrds from Jena,
M. Malarski
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: GnuPT 2.7.6
iD8DBQFD9y9zjJri453BSEQRAieUAKDvXnOYdSah0cJS2BwL9L7JlKwWUgCfZ6CQ
YYvDa2l8SXUh1/wZMWLGdj8=
=aoVw
-----END PGP SIGNATURE-----
.
- References:
- Strang behavior of Backup-Agent 1.0
- From: nmm
- Re: Strang behavior of Backup-Agent 1.0
- From: Bill Bach
- Re: Strang behavior of Backup-Agent 1.0
- From: Leonard
- Strang behavior of Backup-Agent 1.0
- Prev by Date: Re: no server engine, only local workstation engines, Status 116
- Next by Date: Re: no server engine, only local workstation engines, Status 116
- Previous by thread: Re: Strang behavior of Backup-Agent 1.0
- Next by thread: Status 11
- Index(es):
Relevant Pages
|
|