1 |
On Sunday 16 November 2008 13:51:23 Mick wrote: |
2 |
> > Yes. Unix does some RealSmartThings(tm) when using files. The name is |
3 |
> > just a pointer to the actual file, represented by an inode. Once you have |
4 |
> > an inode open, it stays open until everything using it closes it. So you |
5 |
> > can add/delete/copy/move files by name with impunity as you then just |
6 |
> > move names around. Contrast this with other inferior systems, like say |
7 |
> > Windows for example, which has a built-in self-destruct button when you |
8 |
> > try this... |
9 |
> |
10 |
> Sure, but isn't there a problem with atime mtime metadata when you carry |
11 |
> out a backup in real time and then restore from it? |
12 |
|
13 |
With a restore, you have really just two options: |
14 |
|
15 |
- consider the file being restored to be a new file and set the *time to now |
16 |
- consider it a full restore and set them the same as what's in the backup |
17 |
|
18 |
root or the file's owner is permitted to do the latter |
19 |
|
20 |
There's a third option which makes little sense: set the *time of the restored |
21 |
file to be the same as whatever file it is repalcing on disk. But this is |
22 |
mostly silly as the file data is now inconsistent with the recorded times |
23 |
|
24 |
> > > I was gravitating towards using LVM snapshot and then tar'ing that to |
25 |
> > > an external USB drive. |
26 |
> > |
27 |
> > This is the preferred way, as you get a consistent snapshot frozen at a |
28 |
> > point in time. This deals nicely with inconsistencies caused by files |
29 |
> > changing while you are backing up other ones. |
30 |
> |
31 |
> Right, that's what I was thinking too. What does restoring from a backed |
32 |
> up snapshot involve? |
33 |
|
34 |
The backup is just a backup, the fact that it was made from a frozen disk |
35 |
snapshot is irrelevant. So you would restore it in the usual manner for the |
36 |
backup format/method in use |
37 |
|
38 |
-- |
39 |
alan dot mckinnon at gmail dot com |