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
