Andrew Reedick wrote on Mon, Jun 27, 2016 at 20:00:02 +:
> However, I'm not sure what the pros/cons of packing are in regards to rsync.
Packing a repository moves revision data from the existing files to new
files: it basically concatenates each 1000 revision files into a single
file.
I think
> From: Michael Schwager [mailto:mschw...@gmail.com]
> Sent: Wednesday, June 22, 2016 10:25 AM
> To: users@subversion.apache.org
> Subject: Re: Creating and Verifying a Reliable backup
>
> Following is an update to my question of Jun 1, where I ask the following
> questi
Following is an update to my question of Jun 1, where I ask the following
question:
On Wed, Jun 1, 2016 at 9:58 AM, Michael Schwager wrote:
> ...
> My question is: How do I back (subversion repos) up reliably, and verify
> (them) so that I can deliver a 100% recovery guarantee to my boss?
> ...
At least one problem with "svnsync" is that it, by design, does not
propagate the locks. So a sync'd repo cannot replace the sync'd-from
repository without losing all of the locks.
On Thu, Jun 2, 2016 at 9:28 AM, Daniel Shahaf
wrote:
> Michael Schwager wrote on Wed, Jun 01, 2016 at 09:58:18 -05
Pavel Lyalyakin wrote on Wed, Jun 01, 2016 at 19:29:14 +0300:
> Yes, hotcopy makes full repository copy with locks and hook scripts.
> Read SVNBook[2].
For FSFS repositories, 'hotcopy' doesn't backup locks atomically [1];
one workaround to that is to wrap it by a 'freeze', as in 'svnadmin
freeze r
Michael Schwager wrote on Wed, Jun 01, 2016 at 09:58:18 -0500:
> We are very paranoid about our Subversion repo, notwithstanding the fact
> that the previous sysadmin didn't back it up. But that's another story. Now
> I'm here at my job, I've inherited the repo admin duties, and I want to
> back it
>
>
>On Wed, Jun 1, 2016 at 11:20 AM, Stefan Hett
>mailto:ste...@egosoft.com>> wrote:
To ensure the integrity of a backup close to 100% I go the fail safe way:
2. svnadmin dump to dump the current repository
3. svnadmin load the dump into a fresh repository
4. svnadmin dump the newly loaded repos
On Wed, Jun 1, 2016 at 11:20 AM, Stefan Hett wrote:
> To ensure the integrity of a backup close to 100% I go the fail safe way:
> 2. svnadmin dump to dump the current repository
> 3. svnadmin load the dump into a fresh repository
> 4. svnadmin dump the newly loaded repository
> 5. compare the fir
On Wed, Jun 1, 2016 at 11:29 AM, Pavel Lyalyakin <
pavel.lyalya...@visualsvn.com> wrote:
> Hello Michael,
>
> On Wed, Jun 1, 2016 at 7:18 PM, Michael Schwager
> wrote:
> ...
> > My intention is to perform the following:
> ...
> > * svnadmin verify /home/svn/hotcopy/repoX. If error, warn and ex
On Wed, Jun 1, 2016 at 11:20 AM, Stefan Hett wrote:
> On 6/1/2016 4:58 PM, Michael Schwager wrote:
>
> ...we ran into a bug that came about under 1.8 when working with older
> repos; the hotcopy exits with the following error:
>
> svnadmin: E22: Serialized hash missing terminator
>
> As far a
Yessity-yes-yes-ye! svnadmin freeze- I missed that one! That's
something I can really sink my teeth into! Awesome, thanks!
My intention is to perform the following:
* shut down httpd
Then, for each repoX:
* svnadmin verify /home/svn/hotcopy/repoX. If error, warn and exit.
* svnadmin hotcop
On Wed, Jun 1, 2016 at 10:58 AM, Pavel Lyalyakin
wrote:
> Hello Matt,
>
> Why do you use `rsync`?
>
> [1]: http://svnbook.red-bean.com/en/1.8/svn.ref.svnadmin.c.freeze.html
> [2]: http://svnbook.red-bean.com/en/1.8/svn.ref.svnadmin.c.hotcopy.html
I have no good reason! Backup scripts were setup
Hello Michael,
On Wed, Jun 1, 2016 at 7:18 PM, Michael Schwager wrote:
> Yessity-yes-yes-ye! svnadmin freeze- I missed that one! That's
> something I can really sink my teeth into! Awesome, thanks!
>
> My intention is to perform the following:
> * shut down httpd
> Then, for each repoX:
>
On 6/1/2016 4:58 PM, Michael Schwager wrote:
Hello,
We are very paranoid about our Subversion repo, notwithstanding the
fact that the previous sysadmin didn't back it up. But that's another
story. Now I'm here at my job, I've inherited the repo admin duties,
and I want to back it up reliably.
On Wed, Jun 1, 2016 at 11:55 AM, Michael Schwager
wrote:
> Thanks Matt. To your point,
>
> > my collection of backups probably does have some corrupt repo trees...
>
> that is really what I'm driving at. The RAID, offsite, number of backups
> (nightly in our case), and testing is all covered. In
Hello Matt,
On Wed, Jun 1, 2016 at 6:45 PM, Matt Garman wrote:
>
> As you suggested, if you can make a fancier backup script that shuts
> down anyone's ability to make changes to the repo while the backup is
> taking place, that's even better.
There is `svnadmin freeze`[1] for this. And you can
Thanks Matt. To your point,
> my collection of backups probably does have some corrupt repo trees...
that is really what I'm driving at. The RAID, offsite, number of backups
(nightly in our case), and testing is all covered. In other words, I can
mitigate the effects of failure with all those tri
Hello Michael,
On Wed, Jun 1, 2016 at 5:58 PM, Michael Schwager wrote:
> Hello,
> We are very paranoid about our Subversion repo, notwithstanding the fact
> that the previous sysadmin didn't back it up. But that's another story. Now
> I'm here at my job, I've inherited the repo admin duties, and
I think there's two questions here: (1) what are general good backup
practices, and (2) how to backup svn repos specifically.
"If we lose it, we're all out of work." Hopefully your boss
recognizes this and has budgeted appropriately. In my experience
there is no perfect backup; the best you can
Hello,
We are very paranoid about our Subversion repo, notwithstanding the fact
that the previous sysadmin didn't back it up. But that's another story. Now
I'm here at my job, I've inherited the repo admin duties, and I want to
back it up reliably. If we lose it, we're all out of work.
My question
20 matches
Mail list logo