[p4] Is there a way to write-lock the database while my backupruns?

[Robert Cowham]

Another option:

>From p4d -h:

    Checkpointing options:
        -c cmd          lock tables, run command, and exit

I presume you are though doing disk->disk->tape backup, and thus only need
to copy the changed depot files since last backup which should limit the
amount of change happening and thus time required (e.g. rsync or robocopy
would work pretty straight forwardly).

Robert 

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Craig A
> Sent: 21 February 2006 23:39
> To: perforce-user at perforce.com
> Subject: Re: [p4] Is there a way to write-lock the database 
> while my backupruns?
> 
> >> You should re-read...And make sure you understand...
> 
> Thanks very much for your comments. I have read the doc and I 
> do understand how all the pieces work. I am not trying to 
> backup db.* files. We do a weekly checkpoint + nightly 
> journal truncate. Each night we backup the checkpoint/journal 
> files along with the versioned files. We stop the service 
> while this happens to ensure consistency.
> 
> What I am trying to accomplish is (nightly) backing up the 
> versioned files in an absolutely consistent state with the 
> checkpoints+journal files - without stopping the service.
> 
> This is from an older version of the P4 doc:
> http://www.perforce.com/perforce/doc.042/manuals/p4sag/02_backup.html
> 
> 
> "There are rare instances (for instance, users obliterating 
> files during backup, or submitting files on Windows during 
> the file backup portion of the
> process) in which your depot files may change during the 
> interval between the time the checkpoint was taken and the 
> time at which the depot files get backed up by the backup utility. 
> Most sites are [not] affected by these issues; having the 
> Perforce server available on a 24/7 basis is generally a 
> benefit worth this minor risk, especially if backups are 
> being performed at times of low system activity. 
> If, however, the reliability of every backup is of paramount 
> importance, consider stopping the Perforce server before 
> checkpointing, and restarting it after the backup process has 
> completed. Doing so will eliminate all risk of the system 
> state changing during the backup process. "
> 
> And the current doc says:
> 
> "While your versioned files can be newer than the data stored 
> in your checkpoint, it is in your best interest to keep this 
> difference to a minimum" 
> 
> and
> "As you might expect, the shorter this time gap, the better."
> 
> At my site "reliability of every backup is of paramount 
> importance". We have a global operation with heavy usage 
> 24/7. We have no "times of low system activity". It's not 
> clear from the doc what problems might arise from this 
> situation. If there was no problem, then why the two statements above?
> Therefore I conclude there is some possibility of problems 
> and hence my search for some way to lock out writes. I'm not 
> sure why Perforce removed the first quoted note from the doc.
> 
> Robert Cowham mentioned 'p4d -jj'. This does not solve the 
> problem of versioned files being consistent with 
> checkpoint/journal files. You have to ensure there are no 
> versioned files being written to for as long as it takes your 
> backup to complete.
> 
> As Jeff Grills mentioned, there are lots of other database 
> updates besides submitting depotfiles. I would be interested 
> in a lock that only affected operations that would cause a 
> change in the versioned files.
> 
> Also, we don't have the option of using a 'Snap server' to do 
> the ultra-quick snapshots of versioned files.
> 
> Craig