7 messages in com.perforce.perforce-user[p4] Backup script NT| From | Sent On | Attachments |
|---|---|---|
| joha...@esrange.ssc.se | 17 May 2001 00:44 | |
| Chuck Karish | 17 May 2001 03:12 | |
| joha...@esrange.ssc.se | 17 May 2001 04:24 | |
| Paul Goffin | 17 May 2001 04:49 | |
| Chuck Karish | 17 May 2001 09:11 | |
| joha...@esrange.ssc.se | 20 May 2001 23:48 | |
| Chuck Karish | 21 May 2001 07:14 |
| Subject: | [p4] Backup script NT![]() |
|---|---|
| From: | joha...@esrange.ssc.se (joha...@esrange.ssc.se) |
| Date: | 05/17/2001 04:24:30 AM |
| List: | com.perforce.perforce-user |
Thanks for your suggestions, see comments inline.
-----Original Message----- From: Chuck Karish [mailto:karish at well.com] Sent: den 17 maj 2001 12:13 To: johan.nilsson at esrange.ssc.se; perforce-user at perforce.com Subject: Re: [p4] Backup script NT
At 09:44 AM 5/17/2001 +0200, johan.nilsson at esrange.ssc.se wrote:
Hi,
Hi!
trying out Perforce, I'm trying to put together a simple batch to perform automated backups on NT. I'd be grateful for any comments on it (contents included at end of mail). Basically it performs the following steps:
1. p4 verify -q /... 2. p4 verify -q -u //... 3. Stops the perforce server (we can live with this)
There's no need to stop the server. User requests will stall while the checkpoint has the metadata locked.
Yes, but what if someone drops an update to the versioned files after the checkpoint and during/before the file backup (and the versioned files are lost)?
4. p4d -jc
Use the compress-on-the-fly option. You'll save both in writing to disk and in writing to tape.
Thanks, I'll do that.
5. Runs backup of depot, journals and checkpoint files (currently using ntbackup)
This can also be done on a running system. As long as the checkpoint is older, it doesn't matter that the depot files have later mods in them.
See my above comment.
6. Delete old checkpoing and journal files (older than two weeks) 7. Starts the perforce server
I call the script from another short script which simnply redirects all output (including stderr) to a backup log. This will be scheduled to run using the 'at' service ('interact with desktop' enabled).
My intention is to run full ('Normal') backup once a week, differential each night and change tapes each week before the full backup (recycling tapes after three - four weeks).
Do a full dress rehearsal of restoring your server from tape. I'll bet you wind up doing full nightly backups.
Hmm, if I stick to full + differential I'll never have to restore more than two backup sets to get back in business (unless both my harddrive(s) _and_ my tape are wasted, in which case I'll go kill myself anyway).
Don't save two weeks of checkpoints to tape nightly. It'll take forever to find the one you need.
How about the last one? Anyway, if I do full once a week + diff backups the remaining days I won't be saving two weeks nightly (at the most one week, except for in the full backup).
Am I missing something fundamental here?
The procedures I describe work fine with a server that has 10 GP of metadata and 2.5 GB of depot files. Daily logs are half a gig.
10 GP == 10 GB?
// Johan




