1 |
On Thursday, 10 January 2019 08:28:24 GMT J. Roeleveld wrote: |
2 |
> On Thursday, January 10, 2019 1:55:59 AM CET Dale wrote: |
3 |
> > Wols Lists wrote: |
4 |
> > > On 07/01/19 10:46, Dale wrote: |
5 |
> > >> From what I've read, that can be overcome. If you get say a SMART |
6 |
> > >> message that a drive is failing, |
7 |
> > > |
8 |
> > > Yup, I have to agree that SMART isn't always reliable, but if you |
9 |
> > > *monitor* it, it should give plenty of warning of the recording medium |
10 |
> > > failing ... |
11 |
> > |
12 |
> > Yep. It may not detect a spindle motor that is about to fail. I'm sure |
13 |
> > it can't detect that lightening is about to strike and the drive get hit |
14 |
> > with a surge either. It can generally tell if the media is failing |
15 |
> > tho. I've read it can detect some components that are starting to fail |
16 |
> > to, not all but some. Still, even tho it can't detect everything, it is |
17 |
> > better than no warning at all. Until something better comes along, ESP |
18 |
> > maybe, it will have to do. ;-) |
19 |
> > |
20 |
> > >> just remove that drive or remove the |
21 |
> > >> whole LVM setup and use something else until a working drive setup can |
22 |
> > >> be made. Once ready, then move the data, if the drive still works, to |
23 |
> > >> the new drive. That is basically what I did when I swapped a smaller |
24 |
> > >> drive for a larger one. I moved the data from one drive to another. |
25 |
> > >> It |
26 |
> > >> did it fairly quickly. Someone posted that it may even be faster to do |
27 |
> > >> it with LVM's pvmove than it is with cp or rsync. I don't know how |
28 |
> > >> true |
29 |
> > >> that is but from what I've read, it moves the data really efficiently. |
30 |
> > > |
31 |
> > > Point is, it works at a different level. Both cp and rsync are NOT |
32 |
> > > guaranteed to copy your filesystem accurately - mine is full of hard |
33 |
> > > links and that will give both those two a hard and nasty time. |
34 |
> > > |
35 |
> > > LVM copies the block device underneath the file system, so it is less |
36 |
> > > efficient in that it will copy 3GB if you have a 3GB partition, but it |
37 |
> > > is far simpler in that it neither knows nor cares what the file system |
38 |
> > > is doing at the next level up. Give a file-system like mine to "cp -a" |
39 |
> > > and it'll bring the system to its knees trying to keep track of where |
40 |
> > > everything is. |
41 |
> > > |
42 |
> > > Cheers, |
43 |
> > > Wol |
44 |
> > |
45 |
> > That was what I read but couldn't recall enough to tell how it does it. |
46 |
> > That explains why it can be done while in use to. |
47 |
> > |
48 |
> > Just how do you do backups? If cp -a and rsync would not work |
49 |
> > correctly, what do you use? I'm just curious now. ;-) |
50 |
> |
51 |
> There are backup tools that do handle hardlinks correctly. "app-backup/dar" |
52 |
> comes to mind. I know this as my software-share is filled with hardlinks and |
53 |
> when I restore the backup, they are all still there. |
54 |
> |
55 |
> -- |
56 |
> Joost |
57 |
|
58 |
What about 'rsync -H' or 'tar --hard-dereference'? Don't they cater to hard |
59 |
links in the fs? |
60 |
|
61 |
As a block based backup application partclone is also good. It is very |
62 |
efficient in backing up blocks which are occupied by a fs, but not the rest of |
63 |
the empty space. |
64 |
|
65 |
-- |
66 |
Regards, |
67 |
Mick |