| 1 |
On Wed, 2010-08-18 at 14:09 +0300, Nganon wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> On 17 August 2010 22:34, Enrico Weigelt <weigelt@×××××.de> wrote: |
| 5 |
> For things I'd like to keep an history (eg. /etc) I'm using |
| 6 |
> git, and |
| 7 |
> pushing the repo to a remote server (denying non-fastfoward |
| 8 |
> updates |
| 9 |
> there, so an theorectical highjacker cannot destroy my |
| 10 |
> history) |
| 11 |
> |
| 12 |
> |
| 13 |
> Using git for /etc is a great idea. |
| 14 |
> Thanks. |
| 15 |
> |
| 16 |
Another option is: |
| 17 |
* app-backup/dirvish |
| 18 |
Latest version available: 1.2.1 |
| 19 |
Latest version installed: 1.2.1 |
| 20 |
Size of downloaded files: 47 kB |
| 21 |
Homepage: http://www.dirvish.org/ |
| 22 |
Description: Dirvish is a fast, disk based, rotating network |
| 23 |
backup system. |
| 24 |
License: OSL-2.0 |
| 25 |
|
| 26 |
|
| 27 |
Works by first creating a copy (--init) and then hard-linking subsequent |
| 28 |
versions of files/directories back to the original original if its |
| 29 |
identical. If a file is changed/new, it is copied instead of linked so |
| 30 |
actual space usage quickly stabilises even with a varying number of |
| 31 |
versions. Backup over the network (this is how I have configured mine) |
| 32 |
uses rsync over ssh with keys and is "pull" from a cron job on the |
| 33 |
backup server or manual on demand (i.e., server initiated). |
| 34 |
|
| 35 |
Version management is by a reasonably sophisticated date of version |
| 36 |
scheme where by running "dirvish-expire" deletes out of date versions |
| 37 |
(runs in a cron job). The smart part is that once the last hard link to |
| 38 |
file is deleted, its gone, otherwise its kept in the remaining |
| 39 |
versions :) |
| 40 |
|
| 41 |
Restore is a simple matter of identifying the version you want and |
| 42 |
copying it back - Ive restored individual files through to complete |
| 43 |
systems after total disk failure. |
| 44 |
|
| 45 |
Can do includes/excludes, whole systems or just directories such as /etc |
| 46 |
and can be easily automated. |
| 47 |
|
| 48 |
Doesnt use compression, but most backup regimes (every day for a weekly |
| 49 |
rota + a Sunday kept for 6 months) stabilise at about 2x the original |
| 50 |
(gross) copy size, no matter how many copies with average changes |
| 51 |
between versions. Though large scale changes such as an "emerge -e |
| 52 |
world" will take more as it will generate new copies of most files. |
| 53 |
|
| 54 |
Downside is it will hammer the destination file system - reiserfs3 works |
| 55 |
well, ext2/ext3 have been hopeless everytime I've tried - mass |
| 56 |
corruption. The file system will need a large number of inodes (for |
| 57 |
links) if there are an excessive number of files x versions - again |
| 58 |
reiserfs3 scores well here. |
| 59 |
|
| 60 |
Highly recommended! |
| 61 |
|
| 62 |
BillK |
Archives