Thanks for the info.
I have used hotcopy command and that worked fine for a backup.
On Monday, October 7, 2013 3:37:07 PM UTC-4, rvaede wrote:
>
>
>
>I am confused on how to backup my repositary.
>There is an /export/svn directory that holds all the projects
> directories, hook, format l
On 10/7/2013 3:37 PM, rvaede wrote:
>
>
> I am confused on how to backup my repositary.
Note: Making a raw file-level backup of a SVN repository is not
advisable. There may be open files, files that changed while the backup
is running, etc. So you will need to use one of the hotcopy / du
Guten Tag rvaede,
am Montag, 7. Oktober 2013 um 21:37 schrieben Sie:
>I did do a svnadmin dump /export/svn > /test/file.dump
>and I get a very small file, I restored it and it consists of
> hook, format, lock, db, conf and its about 304 KB
A dump shouldn't ever contain the hooks-director
I am confused on how to backup my repositary.
There is an /export/svn directory that holds all the projects
directories, hook, format lock, db etc... its about 14 GB
I did do a svnadmin dump /export/svn > /test/file.dump
and I get a very small file, I restored it and it consists
On 02/15/2012 11:05 AM, Philip Martin wrote:
Stefan Sperling writes:
But rather than going through that effort, I would recommend using
svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
is released. At which point you can switch over to using
"svnadmin hotcopy --incrementa
Stefan Sperling wrote on Thu, Feb 16, 2012 at 13:53:04 +0100:
> On Thu, Feb 16, 2012 at 03:56:29AM +0200, Daniel Shahaf wrote:
> > Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500:
> > > On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
> > > wrote:
> > > > Nico Kadel-Garcia writes:
>
On Thu, Feb 16, 2012 at 6:53 AM, Stefan Sperling wrote:
> >
> > There is no "window of vulnerability".
>
>
> What if the disk controller lies and sends the acknowledgement before
> the actual work has completed (e.g. it cached the write request and is
> going to get to it soon)? How can the OS kn
On Thu, Feb 16, 2012 at 03:56:29AM +0200, Daniel Shahaf wrote:
> Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500:
> > On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
> > wrote:
> > > Nico Kadel-Garcia writes:
> > >
> > >> Unless you do a "sync"
> > >> command, or various low level f
Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500:
> On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
> wrote:
> > Nico Kadel-Garcia writes:
> >
> >> Unless you do a "sync"
> >> command, or various low level flush commands, you don't know that you
> >> write to disk has actually made i
On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
wrote:
> Nico Kadel-Garcia writes:
>
>> Unless you do a "sync"
>> command, or various low level flush commands, you don't know that you
>> write to disk has actually made it to the platter.
>
> Subversion does that. It uses fsync (plus fsync on dire
Nico Kadel-Garcia writes:
> Unless you do a "sync"
> command, or various low level flush commands, you don't know that you
> write to disk has actually made it to the platter.
Subversion does that. It uses fsync (plus fsync on directories on
Linux) before assuming data is on disk.
--
Philip
On Wed, Feb 15, 2012 at 3:37 PM, Nico Kadel-Garcia wrote:
> If the repository is busy in a commit or partial commit at the moment
> of the snapshot, you're in potentially very deep trouble. You've
> entered not only "split-brain" territory, where the repositories are
> out of sync, but partial c
On Wed, Feb 15, 2012 at 2:05 PM, Philip Martin
wrote:
> Stefan Sperling writes:
>
>> But rather than going through that effort, I would recommend using
>> svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
>> is released. At which point you can switch over to using
>> "svnadmi
On Wed, 15 Feb 2012 20:41:48 +, Stefan Sperling wrote:
> I don't know enough about SQlite to judge whether the DB will
> keep working at any frozen state a snapshot might create.
If it doesn't then it wouldn't be resilient to system crashes either,
and *that* wouldn't exactly be a recomme
On Wed, Feb 15, 2012 at 07:05:08PM +, Philip Martin wrote:
> Stefan Sperling writes:
>
> > But rather than going through that effort, I would recommend using
> > svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
> > is released. At which point you can switch over to using
Stefan Sperling writes:
> But rather than going through that effort, I would recommend using
> svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
> is released. At which point you can switch over to using
> "svnadmin hotcopy --incremental", which will copy rep-cache.db via
> t
On Wed, Feb 15, 2012 at 12:03:15PM -0500, Harry Bullen wrote:
> From what I gather rep-cache.db, can be
> regenerated by svn. If I used rsync and excluded the rep-cache.db
> would I then want to run 'svnadmin recover' on these backup or is
> rep-cache.db regenerated automatically when the reposit
Harry Bullen wrote on Wed, Feb 15, 2012 at 12:03:15 -0500:
> On Wed, Feb 15, 2012 at 6:24 AM, Stefan Sperling wrote:
> > On Wed, Feb 15, 2012 at 03:02:04AM +0200, Daniel Shahaf wrote:
> >> Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
> >> > Until then, svnsync or svnadmin dump/loa
On Wed, Feb 15, 2012 at 6:24 AM, Stefan Sperling wrote:
> On Wed, Feb 15, 2012 at 03:02:04AM +0200, Daniel Shahaf wrote:
>> Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
>> > Until then, svnsync or svnadmin dump/load are the only officially
>> > supported incremental backup solutio
On Wed, Feb 15, 2012 at 03:02:04AM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
> > Until then, svnsync or svnadmin dump/load are the only officially
> > supported incremental backup solutions. But, as Daniel explained,
> > 'rsync' followed by 'svnadmi
Les Mikesell wrote on Tue, Feb 14, 2012 at 19:34:10 -0600:
> On Tue, Feb 14, 2012 at 7:02 PM, Daniel Shahaf
> wrote:
> > Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
> >> Until then, svnsync or svnadmin dump/load are the only officially
> >> supported incremental backup solutions
On Tue, Feb 14, 2012 at 7:02 PM, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
>> Until then, svnsync or svnadmin dump/load are the only officially
>> supported incremental backup solutions. But, as Daniel explained,
>> 'rsync' followed by 'svnadmin recover'
Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
> Until then, svnsync or svnadmin dump/load are the only officially
> supported incremental backup solutions. But, as Daniel explained,
> 'rsync' followed by 'svnadmin recover' produces valid copies of
> FSFS repositories, too.
I didn't
On Tue, Feb 14, 2012 at 02:11:29PM -0500, Harry Bullen wrote:
> The repositories total about 200GB (some
> people might have committed movies to svn but I may not fix this)
> which is why I want to do this instead of svn hotcopy, which will have
> to copy all 200GB every day.
Subversion 1.8 will s
On Tue, Feb 14, 2012 at 1:11 PM, Harry Bullen wrote:
> I'm looking at using lvm snapshots and rsync to back up a bunch of svn
> repositories every night. The repositories total about 200GB (some
> people might have committed movies to svn but I may not fix this)
> which is why I want to do this
If the snapshots are atomic that's fine, though you'll potentially need
to run 'svnadmin recover' before they're usable.
Running dump / verify or otherwise verifying your snapshots remains
a good idea.
Harry Bullen wrote on Tue, Feb 14, 2012 at 14:11:29 -0500:
> I'm looking at using lvm snapshots
On Tue, Feb 14, 2012 at 2:11 PM, Harry Bullen wrote:
> I'm looking at using lvm snapshots and rsync to back up a bunch of svn
> repositories every night. The repositories total about 200GB (some
> people might have committed movies to svn but I may not fix this)
> which is why I want to do this i
I'm looking at using lvm snapshots and rsync to back up a bunch of svn
repositories every night. The repositories total about 200GB (some
people might have committed movies to svn but I may not fix this)
which is why I want to do this instead of svn hotcopy, which will have
to copy all 200GB every
Please keep this discussion on the mailing list by using the Reply All function.
On May 4, 2010, at 02:40, Vikrama Sanjeeva wrote:
> On Tue, May 4, 2010 at 1:05 AM, Ryan Schmidt wrote:
>
>> Please consider backing up each revision as it is committed, in a
>> post-commit hook. That way you won't
On May 3, 2010, at 11:09, Vikrama Sanjeeva wrote:
> We've recently shifted to SVN. Suppose there are three repositories R1, R2
> and R3. And each repostory has three projects in it.
>
> So we have:
> R1: P1, P2, P3
> R2: P1, P2, P3
> R3: P1, P2, P3
>
> R1-P1 and R1-P2 are changed almost daily,
Hello,
We've recently shifted to SVN. Suppose there are three repositories R1, R2
and R3. And each repostory has three projects in it.
So we have:
R1: P1, P2, P3
R2: P1, P2, P3
R3: P1, P2, P3
R1-P1 and R1-P2 are changed almost daily, whereas, R1-P3 is changed very
rare (once a month)
Change of
31 matches
Mail list logo
