Jump to content


Recommended number of checkpoints / journals to keep.

checkpoint

  • Please log in to reply
2 replies to this topic

#1 dgnuff

dgnuff

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 08 August 2020 - 08:42 AM

I've been using the free 5 user P4D that you get with a standard Helix Core install to learn the inner workings of Perforce, and to back up my personal work.

It's been working like a champ for a couple of years now, but I noticed some time ago that the journal was getting a bit on the big side.  A little research told me that I need to be checkpointing to keep its size in check.  That's been running just fine, but now I start to wonder just how many checkpoint / journal pairs should I actually keep?

My understanding is that just the most recent checkpoint and journal together with the depot backup should be enough to recover from a complete disaster.  However, that feels to me like I'm putting all my eggs in one basket, which for backup is a very bad idea.  Search for the 3-2-1 backup strategy for an explanation of why.

So is there any additional benefit in keeping a couple of previous checkpoints and their associated journal files, and if so how many is a reasonable number?

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 1192 posts

Posted 08 August 2020 - 04:33 PM

If you want to avoid keeping all your eggs in one basket, that's more about making sure that your backups (i.e. checkpoints and archive backups) live someplace safe (i.e. not on the same disk as your live db, and either multiple physical copies or some sort of highly durable storage solution that has the same effect).  For a small personal server my approach would be to just keep backups in some kind of cloud storage (Dropbox or GDrive or whatever you're already using -- most cloud storage services have pretty good durability guarantees).  For a single-user Perforce server that's only holding source code and maybe a few small binary assets, I doubt storage space would ever be a major consideration.

If storage space is a consideration, keeping old checkpoints/journals is mostly about being able to recover historical data, either for auditing purposes (e.g. if you want to use old journals to debug some specific sequence of events from a month ago to figure out what exactly one of your users did to get their workspace in this state) or to recover from a serious mistake (e.g. someone with admin permission did an obliterate and you want to reverse it).  How far back do you want to be able to go in one of those situations?  That's a function of both (1) how much you care about having that level of control/security and (2) if you DO care, how good you are at monitoring and how long it'll take you to realize that sort of mitigation is something you want to do.

For a server that you are the only one using, and one where you're doing personal projects that don't have legal auditing requirements, you probably don't really care that much.  :)  If you mess up an obliterate, you're almost definitely going to realize your error right away, rather than finding out about it a year later and having to go fetch the tape backups from the cold storage warehouse.

#3 dgnuff

dgnuff

    Newbie

  • Members
  • Pip
  • 5 posts

Posted 08 August 2020 - 10:25 PM

Thanks for your reply.  The traffic on my server is sufficiently light that I can easily get away checkpointing every two weeks.  So saving current checkpoint and four previous ones should allow me to see anything up to two months ago.  That will be plenty enough for my needs.

Also, the server has several drives, so I can easily move the checkpoints off to a separate volume.  I'd seen the [prefix] option in the documentation for p4 admin checkpoint. so that'll be trivial to do.  Of course, the main depot and checkpoints are backed up daily as part of my regular backup strategy, so I should be about as close to bulletproof as it's possible to get.





Also tagged with one or more of these keywords: checkpoint

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users