On 14.10.2019 15:25, Anton Shepelev wrote:
>> See the example mentioned in the 1.8 release notes [1]:
>>
>> svnadmin freeze /svn/my-repos -- rsync -av /svn/my-repos /backup/my-repos
> Hmm. I should also expect a simple freeze/unfreeze pair
> with the caller resposible for unfreezing a fronzen r
Johan Corveleyn
>Just to mention another option: Since 1.8 there is the
>command 'svnadmin freeze', which locks the repository for
>writing while you run another command. That way, you can
>use regular backup / copy commands (like rsync) to create a
>consistent copy.
I think `freeze' is also help
On Tue, Aug 27, 2019 at 5:06 AM Johan Corveleyn wrote:
> On Mon, Aug 26, 2019 at 9:01 PM Mark Phippard wrote:
> >
> > On Mon, Aug 26, 2019 at 1:29 PM Anton Shepelev
> wrote:
> >>
> >> I have now set up a post-commit hook that makes an
> >> --incremental hotcopy. With the destination on the sam
On Mon, Aug 26, 2019 at 9:01 PM Mark Phippard wrote:
>
> On Mon, Aug 26, 2019 at 1:29 PM Anton Shepelev wrote:
>>
>> I have now set up a post-commit hook that makes an
>> --incremental hotcopy. With the destination on the same
>> machine's HDD, it takes about two seconds, but with a
>> network s
On Mon, Aug 26, 2019 at 1:29 PM Anton Shepelev wrote:
> I have now set up a post-commit hook that makes an
> --incremental hotcopy. With the destination on the same
> machine's HDD, it takes about two seconds, but with a
> network share it lasts 30 seconds. Is it expected behavior
> for committ
I have now set up a post-commit hook that makes an
--incremental hotcopy. With the destination on the same
machine's HDD, it takes about two seconds, but with a
network share it lasts 30 seconds. Is it expected behavior
for committing a tiny change in a text file? If not, then
where shall I look
Thank you for your comments, Andreas:
> Literally any situation where the undesired change to be
> recovered from happened before this last and single copy
> was taken.
I am going to prevent this by means of `svnadmin verify':
> > Is it practical to call it [verify] daily with a several
> > Gb,
Hi,
> > A hobbyist approach this this has lead to many instances
> > of data loss in serious applications.
>
> While planning a backup strategy, one must consider the
> possible malfunctions and ways to counteract them. How was
> the data lost in the cases you describe?
Literally any situation w
Andreas Stieger to Anton Shepelev:
> > No, it depends on one's purpose. If it is to keep the
> > data in case of HDD crashes, a single mirror is
> > sufficient.
>
> A hobbyist approach this this has lead to many instances
> of data loss in serious applications.
While planning a backup strategy,
> No, it depends on one's purpose. If it is to keep the data
> in case of HDD crashes, a single mirror is sufficient.
A hobbyist approach this this has lead to many instances of data loss in
serious applications.
> again, since an SVN repository maintains its whole history,
> a point-in-time
Andreas Stieger to Anton Shepelev:
> > Thanks to everybody for their replies. I now understand
> > that -- incremental hot-copies are sufficient for
> > regular backups, which can then be mirrored by content-
> > aware file- synchronisation tools, but the problem
> > remains of preventing an acci
Hello,
> that --incremental hot-copies are sufficient for regular
> backups, which can then be mirrored by content-aware file-
> synchronisation tools, but the problem remains of preventing
> an accidental propagation of corrupt data into the backup.
> How do you solve it?
What the fruit do you m
Thanks to everybody for their replies. I now understand
that --incremental hot-copies are sufficient for regular
backups, which can then be mirrored by content-aware file-
synchronisation tools, but the problem remains of preventing
an accidental propagation of corrupt data into the backup.
How do
Le ven. 23 août 2019 à 17:10, Mark Phippard a écrit :
>
> On Fri, Aug 23, 2019 at 11:06 AM Nathan Hartman
> wrote:
>>
>> On Fri, Aug 23, 2019 at 9:53 AM Mark Phippard wrote:
>>>
>>> Anyway ... the only danger of a repository format is if you upgrade to
>>> latest and then for some reason need
On Fri, Aug 23, 2019 at 11:06 AM Nathan Hartman
wrote:
> On Fri, Aug 23, 2019 at 9:53 AM Mark Phippard wrote:
>
>> Anyway ... the only danger of a repository format is if you upgrade to
>> latest and then for some reason need to downgrade your server binaries to
>> an older version. You can alw
On Fri, Aug 23, 2019 at 9:53 AM Mark Phippard wrote:
> Anyway ... the only danger of a repository format is if you upgrade to
> latest and then for some reason need to downgrade your server binaries to
> an older version. You can always use an older format with a newer version.
>
If you did wis
On Fri, Aug 23, 2019 at 4:16 AM Pierre Fourès
wrote:
> Hello,
>
> Le jeu. 22 août 2019 à 16:47, Mark Phippard a écrit :
> >
> >
> >> Cannot they become obsolete when a new version of SVN comes
> >> out?
> >
> >
> > No. It is a valid copy of the repository.
> >
> >> Are they portable across op
Hello,
Le jeu. 22 août 2019 à 16:47, Mark Phippard a écrit :
>
>
>> Cannot they become obsolete when a new version of SVN comes
>> out?
>
>
> No. It is a valid copy of the repository.
>
>> Are they portable across operating systems and
>> filesystems? (I fear not)
>
>
> Yes, they are absolutel
On Thu, Aug 22, 2019 at 9:52 AM Anton Shepelev wrote:
>
> [replying via Gmane]
>
> Andreas Stieger:
>
> >The dump format is not the best option for backups. The
> >restore time is much too slow as you need to recover from a
> >serialized format. In many hand-baked scripts the dump
> >method misses
Mark Phippard:
>Almost no one uses the BDB repository format. The fsfs
>format became the default in SVN 1.1 or 1.2 and it is the
>only format used anymore.
Phew. We do have FSFS. Thank you.
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
On Thu, Aug 22, 2019 at 10:55 AM Anton Shepelev wrote:
> Mark Phippard to Anton Shepelev about hot copies:
>
> >>Are they portable across operating systems and
> >>filesystems? (I fear not)
> >
> >Yes, they are absolutely portable across OS and FS. As is
> >the repos itself. The only issue when
Mark Phippard to Anton Shepelev about hot copies:
>>Are they portable across operating systems and
>>filesystems? (I fear not)
>
>Yes, they are absolutely portable across OS and FS. As is
>the repos itself. The only issue when going across these
>is managing the OS level permissions of the copy.
On Thu, Aug 22, 2019 at 10:38 AM Anton Shepelev wrote:
> Mark Phippard:
>
> >My first choice option would be to setup a repository on a
> >second server and use svnsync from a post-commit hook
> >script to sync the change. After that, I would use
> >svnadmin hotcopy with the new --incremental op
Mark Phippard:
>My first choice option would be to setup a repository on a
>second server and use svnsync from a post-commit hook
>script to sync the change. After that, I would use
>svnadmin hotcopy with the new --incremental option (as of
>1.8?). Dump is not a great choice for backups.
Thank
Hello,
Le jeu. 22 août 2019 à 15:52, Anton Shepelev a écrit :
>
> Andreas Stieger:
>
> >The dump format is not the best option for backups. The
> >restore time is much too slow as you need to recover from a
> >serialized format. In many hand-baked scripts the dump
> >method misses point-in-time r
On Thu, 22 Aug 2019 09:38:02 -0400, Mark Phippard wrote:
>My first choice option would be to setup a repository on a second server
>and use svnsync from a post-commit hook script to sync the change. After
>that, I would use svnadmin hotcopy with the new --incremental option (as of
>1.8?). Dump
[replying via Gmane]
Andreas Stieger:
>The dump format is not the best option for backups. The
>restore time is much too slow as you need to recover from a
>serialized format. In many hand-baked scripts the dump
>method misses point-in-time recovery capabilities, ->
Why should I need those if SV
On Thu, Aug 22, 2019 at 9:16 AM Anton Shepelev wrote:
> [Having failed to post this message via Gmane, I am sending it by e-mail]
>
> Hello, all
>
> In order to write a backup script in the Windows batch
> language, I was reading the section "Migrating Repository
> Data Elsewhere" from "Repositor
Hello,
> In order to write a backup script in the Windows batch
> language, I was reading the section "Migrating Repository
> Data Elsewhere" from "Repository Maintenance":
>
>http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html
The dump format is not the best option for backups. The
29 matches
Mail list logo
