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, one must consider the
possible malfunctions and ways to counteract them. How was
the data lost in the cases you describe?
> > Then again, since an SVN repository maintains its whole
> > history, a point-in-time recovery is easily effected by
> > `svn up -r N'.
> That is application level (versioning), different from
> file level backup.
Yes, but it seems largely to withdraw the need of file-level
history. All I need is a backup of a recent version of the
repository wihout data corruption.
> > The only potential problem is some quiet data
> > corruption, which is why I ask: will `hotcopy' propagate
> > data corruption or will it detect it via internal
> > integrity checks and fail?
> Your concern about silent data corruption is not
> consistent with your "a copy is a backup" statement. Why
> would you care about one while accepting the other?
As I said, it is "the only potential problem."
> That being said, hotcopy will copy corruptions that may
> have happened, even if in the incremental case will only
> do so when first processed. svnadmin verify is suitable
> for an integrity check.
Dumps are very slow. `svnadmin verify' emulates a dump. Is
it equally slow? Is it practical to call it daily with a
several Gb, several thousand-revision repository?
Please, do not forward replies to my e-mail.
Received on 2019-08-24 15:16:30 CEST