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.
