1 |
On Thu, Sep 1, 2016 at 2:58 PM, gevisz <gevisz@×××××.com> wrote: |
2 |
> 2016-09-01 14:55 GMT+03:00 Rich Freeman <rich0@g.o>: |
3 |
> |
4 |
>> 2. Set it up as an LVM partition. Unless you're using filesystems |
5 |
>> like zfs/btrfs that have their own way of doing volume management, |
6 |
>> this just makes things less painful down the road. |
7 |
>> |
8 |
>> 3. I'd probably just set it up as one big logical volume, unless you |
9 |
>> know you don't need all the space and you think you might use it for |
10 |
>> something else later. You can change your mind on this with ext4+lvm |
11 |
>> either way, but better to start out whichever way seems best. |
12 |
> |
13 |
> I had to refresh my memory about LVM before replying to you |
14 |
> but still can not see why I may need LVM on an external |
15 |
> hard drive... |
16 |
|
17 |
It just gives you more options in the future, it is easy to move LVM |
18 |
volumes to other drives, re-partition them later, and so on. I agree |
19 |
it is probably overkill on a removable device, but it doesn't hurt. |
20 |
This is a 5TB drive after all. But, I don't think it is |
21 |
super-critical either. |
22 |
|
23 |
> |
24 |
>> It will take you all of 30 seconds to format this, unless you're |
25 |
>> running badblocks (which almost nobody does, because... |
26 |
> |
27 |
> it takes too much time? |
28 |
> |
29 |
> I currently running a smart test on it, and it promised to take |
30 |
> 10 hours to complete... |
31 |
|
32 |
That's basically it. If it didn't take time people would of course |
33 |
run it first. I think a SMART test would be about as good and likely |
34 |
a lot faster. However, the drive should be managing bad blocks on its |
35 |
own (granted, many drives seem to get that wrong in my experience, |
36 |
which is part of why I run btrfs, but I probably wouldn't use |
37 |
btrfs/zfs for a drive you're moving all over the place since who knows |
38 |
what kind of kernel you'll have when you use it and heaven help you if |
39 |
you ever need to read it on Windows). |
40 |
|
41 |
> |
42 |
>> You seem to be concerned about losing data. You should be. This is a |
43 |
>> physical storage device. You WILL lose everything stored on it at |
44 |
>> some point in time. |
45 |
> |
46 |
> Last time, I have managed to restore all the data from my 2.5" hard |
47 |
> drive that suddenly died about 7 years ago and hope to do it again |
48 |
> if any. :) |
49 |
|
50 |
Well, if the data is redundant then you're fine (it is essentially |
51 |
already backed up). But, you should check those backups from time to |
52 |
time. |
53 |
|
54 |
You should never rely on the ability to recover data from a hard |
55 |
drive. For starters, if you just lose the thing (portable things can |
56 |
sometimes grow legs; you're talking about 5 libraries of congress in a |
57 |
bag that could get stolen) or it is catastrophically destroyed that |
58 |
isn't going to work. Short of that there is a fair chance you can get |
59 |
a lot of data off the drive, and it is fairly likely if you're using |
60 |
some kind of expensive recovery service, but you can't promise that |
61 |
the specific file you care about most will get recovered. |
62 |
|
63 |
Backups are annoying. I don't do them as well as ideally I should |
64 |
(way too much data to get it all offsite), but I make a conscious |
65 |
decision about what does/doesn't get backed up and how. I |
66 |
occasionally restore my encrypted cloud backups to confirm they |
67 |
contain what I expect them to. I actually get the log summary emailed |
68 |
daily to make sure it is running (if I had more hosts I could use some |
69 |
kind of monitoring for that...). I've never needed to use the online |
70 |
cloud backups, but they're there for a reason and they cover anything |
71 |
I actually care about (documents and such). I also backup all my |
72 |
cloud services (evernote, google drive, etc) to local storage |
73 |
occassionally; that doesn't require further backup since it is the |
74 |
backup. You just need two copies of everything, with one copy |
75 |
preferably being inaccessible from the other and not at the same |
76 |
physical site. |
77 |
|
78 |
-- |
79 |
Rich |