Re: Questions about a script for regular backups

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.