AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Larry.Scheer@lsi.com>,<Tonica.Nguy@lsi.com>,<Jobi.Ariyamannil@lsi.com>,<Brian.Stark@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	DEC609CD0E54B2448DAF023C89AE9755EB50C3C7@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Fri, 22 Jan 2010 11:08:54 -0800
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Scheer, Larry" <Larry.Scheer@lsi.com>
Cc: "Nguy, Tonica" <Tonica.Nguy@lsi.com>, "Ariyamannil, Jobi"
 <Jobi.Ariyamannil@lsi.com>, "Stark, Brian" <Brian.Stark@lsi.com>
Subject: Re: Perforce backup
Message-ID: <20100122110854.20328b6e@ripper.onstor.net>
In-Reply-To: <DEC609CD0E54B2448DAF023C89AE9755EB50C3C7@cosmail02.lsi.com>
References: <DEC609CD0E54B2448DAF023C89AE9755EB50C3BB@cosmail02.lsi.com>
	<20100122013604.54c0e82c@ripper.onstor.net>
	<DEC609CD0E54B2448DAF023C89AE9755EB50C3C7@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Right, I understand all that, what I'm saying is the "meta-data" is the
database, and that's where all the changes and other info is.  The
depot is just the top of each branch.  That's why I'm expecting/hoping
that rsync will be a big help to us.

a


On Fri, 22 Jan 2010 11:22:15 -0700 "Scheer, Larry"
<Larry.Scheer@lsi.com> wrote:

> No, not really. What the backup creates is a checkpoint file of the
> databases and that is one of the things being transferred. I don't
> know how rsync would treat this file and if it would be able to
> transfer only the deltas. We would see a big "win" if we used rsync
> to transfer the depot version files. But the file portion is less
> than half the size of the meta-data (databases.)
> 
> I will think about this and do a little more research to see if there
> is an alternative way of backing up the p4 databases besides creating
> the checkpoint file.
> 
> Larry
> ________________________________________
> From: Andrew Sharp [andy.sharp@lsi.com]
> Sent: Friday, January 22, 2010 1:36 AM
> To: Scheer, Larry
> Cc: Nguy, Tonica; Ariyamannil, Jobi; Stark, Brian
> Subject: Re: Perforce backup
> 
> On Wed, 20 Jan 2010 14:58:03 -0700 "Scheer, Larry"
> <Larry.Scheer@lsi.com> wrote:
> 
> > Hi Tonica,
> >   This email is a recap of what we discussed in our meeting today
> > regarding the perforce backup.
> >
> > The backup of a Perforce SCM system has two components.
> > 1.) A checkpoint of the perforce data bases (all meta-data)
> > 2.) An archive file (tar format) of the file repository (files and
> > their revisions)
> >
> > Both of these components are needed to recover a fully functional
> > perforce server and its depot (source repository.) Perforce does not
> > provide an incremental backup solution. They do provide a way to
> > recover from a partial or out of date checkpoint using journal files
> > but that does not apply to how I am currently doing backups and it
> > will not provide LSI IT department with an incremental backup
> > solution.
> >
> > Also I need to quickly recover the perforce server after a failure
> > and I simply need full backups in order to get up and running in as
> > little down time as possible.
> >
> > The database checkpoint is currently around 19 Gbytes.
> >
> > The repository archive is currently around 7.25 Gbytes.
> >
> > The Perforce server backup starts at 1 AM and finishes just before 2
> > AM Monday through Friday and Sunday. The Perforce database is locked
> > while the backup runs.
> >
> > On Saturdays the backup script runs a database integrity check and
> > that runs from 1 AM until 4:33 AM. The backup completes at 5:30 AM.
> > Again the Perforce database is locked while the backup runs.
> >
> > It was good meeting with you today and getting the details worked
> > out.
> 
> Ideally we can use rsync to help us deal with transfering this large
> piece of data.  Since much of the database doesn't change from week to
> week, rsync should be of great benefit in xfering only the parts of
> the database that have changed, greatly lowering the payload we
> actually have to transfer.
> 
> Larry, Tonica, do you guys agree with this?
> 
> Cheers,
> 
> a
