4 messages in com.perforce.perforce-userDoes p4d die gracefully? Example bac...| From | Sent On | Attachments |
|---|---|---|
| BobA...@weblogic.com | 13 Jan 1998 20:09 | .p4backup, .p4 |
| Gerd...@bitart.com | 13 Jan 1998 20:25 | |
| WesP...@xmission.com | 13 Jan 1998 22:43 | |
| Jame...@perforce.com | 14 Jan 1998 15:34 |
| Subject: | Does p4d die gracefully? Example backup script.![]() |
|---|---|
| From: | WesP...@xmission.com (WesP...@xmission.com) |
| Date: | 01/13/1998 10:43:46 PM |
| List: | com.perforce.perforce-user |
Gerd Knops wrote:
boba at weblogic.com (Bob Andrews) wrote:
I'll let PERFORCE answer your question about killing the server. It's one I asked recently, too.
To backup the depot, however, you don't need to kill the server processes. You can checkpoint the depot while the server is up, then backup the checkpoint file, database files, and depot tree.
You don't need to backup the database files, since the restore process will restore them from the checkpoint file. You'll end up wasting a lot of tape and disk space also, since the database files may be full of holes. (This according to a recent conversation I had with Perforce regarding backups).
We have a shop that's nearly 24x7 (due to crazy developer hours, not worldwide development). I've posted our backup script, p4backup, on the PERFORCE web site, but I made some recent changes, so I've attached the most recent copy to this email. The /etc/init.d/p4 script that p4backup uses is also attached. The scripts are written in Bourne shell and are used on Solaris 2.5.1. Hope this helps.
I strongly suggest checking the return status of p4d when checkpointing.
Very good point as well. I'll add it to my backup script tomorrow.
Here is what I'm using now. Currently, our Perforce depot is small enough that we just add a full backup of the depot to a single tape each day, and exchange the tapes on Monday. The script runs at 0300 Tuesday through Saturday, and automagically retensions the tape on Tuesday and rewinds it on Saturday:
#! /bin/sh # # Checkpoint and backup the Perforce depot. # # If this is the Monday night/Tuesday morning backup, retension # the tape to start off the weeks work. This will loosen up the # tape media and rewind the tape. Somebody should have put a # new tape in the drive during the workday on Monday.
if [ `date +%u` = "2" ] ; then echo "Retensioning..." mt -f /dev/nrst0 retension fi
echo "Checkpointing..." /usr/local/bin/p4d -r /usr/local/p4root -jc checkpoint.backup
echo "Backing up..." cd /usr/local/p4root tar cvbf 10240 /dev/nrst0 depot checkpoint.backup license
# If this is the Saturday morning backup, rewind the tape to # finish off the weeks work. This will make it much quicker # to eject the tape when it is exchanged on Monday.
if [ `date +%u` = "6" ] ; then echo "Rewinding..." mt -f /dev/nrst0 rewind echo echo echo "Change the Tape!" fi
As mentioned above, I need to check the return value for the checkpoint operation and log an error if it does not succeed. Since this script is run by a cron job, the output of the script is emailed to the root account on this machine after each run, which is sufficient logging for our needs.
This script is started by the following cron entry for the root account:
# Precisely at 3:00 am, checkpoint the Perforce database(s) and kick off # the backup.
0 3 * * 2-6 /root/backup.depot
One other item that stood out as I reviewed this message: don't forget to backup your server license file! ;^)
--- "Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr at xmission.com





.p4backup, .p4