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
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
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,
28 matches
Mail list logo
