Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm looking for the best way to backup my pervasive database. I've read the documentation but still have a few questions.

It appears that Continuous Operations method only allows me to backup the entire database? So I'd do butil -startbu @filelist, then backup the entire database (copy, rsync, etc), then run butil -endbu @filelist. Looking through the documentation I don't see a way to get transaction logs out of this method; like I would do for MSSQL (BACKUP LOG ACCT TO DISK) or Postgres (archive_command). With rsync, it might be feasible to still do this every 15 minutes.

The Archival Logging method means I would have to occasionally stop the database to get a full backup, which is acceptable for me. But can I copy the log files off of the server every 15 minutes, ie log shipping?

Thank you.

share|improve this question
    
Is this Pervasive SQL or Pervasive Transactional (btrieve)? –  Mark Henderson Feb 10 '11 at 2:52
    
Just thought I'd mention that Pervasive also have a Backup Agent option that you can add onto the server. When started, it'll quiesce the DB and allow you to directly backup the live db files. –  Chris Thorpe Feb 10 '11 at 3:01
    
The backup agent is just a friendly face over butil from what I can tell. –  Steven Feb 10 '11 at 3:21
    
How can I definitely tell if these tables are SQL or btrieve? This is pervasive v10. On the file system the tables are DAT files. –  Steven Feb 10 '11 at 3:42
    
@Mark - from reading this, it seems like if some requirements (fairly(?) common) are met, a single Pervasive DB could be accessed using Transactional (Btrieve) or relational (SQL) methods. –  mfinni Feb 10 '11 at 4:26
show 1 more comment

2 Answers

up vote 1 down vote accepted

From reading the rest of that chapter, it appears your surmise is correct. There is no equivalent to MS-SQL log shipping.

Restoring Data Files when Using Continuous Operations If you are using Continuous Operations for your backup strategy, then you have no recovery log that can be used to recover changes since your last backup. All database changes since your last backup are lost, with the possible exception of any transactions stored in the transaction log. Any such transactions are automatically rolled forward by the database engine when it starts up.

Thus, there are transaction logs, but it doesn't seem that the system puts any sort of structure around shipping them or assuring that they're doing what you would count on them to be doing. IOW, I don't know how you'll confirm that any given transacation log is consistent with any given full backup takenw ith Continuous Operation.

If you want to do archival logging every 15 minutes, you have to shut down the DB every 15 minutes. That's not a normal mode of operation for most production databases - does your environment allow that?

share|improve this answer
    
With the archiving method, I was hoping I could ship the logs every 15 minutes, while keeping the DB running. But as you say, that doesn't seem possible. –  Steven Feb 10 '11 at 4:45
add comment

My understanding on the archival logs is that you have to manually delete them after each backup as they are constantly being written to, so you could potentially back them up every 15min.

Initial Step: Stop the db, create a backup, turn archival on, start db Then, you could backup the archives every 15min for ~24hrs. Next full backup: Stop the db, create a backup, delete/rename archives, start db Then, you could backup the archives every 15min for ~24hrs. Next full backup: Stop the db, create a backup, delete/rename archives, start db ....so on

The reason, as I understand it, is that if you don't delete/rename the archives, it will still include all the changes since your first backup (which are in your newer backup already). The maintenance of the archives is YOUR responsibility...doesn't seem like there is anything automated around this.

From the Advanced Operations Guide

"After a successful backup, delete all existing archival logs.

Caution: Delete the corresponding log files before you resume working with the data files. Synchronizing the backup data files and the corresponding log files is a critical factor of successful recovery."

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.