Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #230062 > unrolled thread

mdadm usage

Back to article view | Back to linux.debian.user

Contents

  mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-29 08:10 +0100
    Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-29 08:30 +0100
      Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-29 09:40 +0100
    Re: mdadm usage Felix Miata <mrmazda@earthlink.net> - 2020-12-29 08:50 +0100
      Re: mdadm usage basti <mailinglist@unix-solution.de> - 2020-12-29 09:40 +0100
        Re: mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-29 21:40 +0100
          Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2020-12-30 00:00 +0100
          Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 02:00 +0100
            Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-30 02:30 +0100
              Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 09:20 +0100
              Re: mdadm usage Jesper Dybdal <jd-debian-user@dybdal.dk> - 2020-12-30 14:40 +0100
                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 15:00 +0100
                  Re: mdadm usage Jesper Dybdal <jd-debian-user@dybdal.dk> - 2021-01-02 14:40 +0100
                mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-30 15:10 +0100
                  Re: mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-30 15:10 +0100
                    Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 21:50 +0100
                      Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-30 22:40 +0100
                        Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 23:20 +0100
                          Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 00:30 +0100
                            Re: mdadm usage rhkramer@gmail.com - 2020-12-31 13:30 +0100
                              Re: mdadm usage Michael Stone <mstone@debian.org> - 2020-12-31 15:20 +0100
                                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 15:30 +0100
                          Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-31 15:50 +0100
                            Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 16:10 +0100
                              Re: mdadm usage Reco <recoverym4n@enotuniq.net> - 2020-12-31 16:20 +0100
                                Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-31 16:40 +0100
                                  Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-01 23:10 +0100
                                    Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 09:40 +0100
                                      Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 10:10 +0100
                                        Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 11:30 +0100
                                        Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2021-01-02 14:50 +0100
                                          Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 16:40 +0100
                                            Re: mdadm usage Linux-Fan <Ma_Sys.ma@web.de> - 2021-01-02 18:10 +0100
                                      Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 10:40 +0100
                                        Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 12:00 +0100
                                          Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 12:30 +0100
                                            Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 12:50 +0100
                                              Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2021-01-02 13:10 +0100
                                                Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 14:20 +0100
                                              Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2021-01-02 14:10 +0100
                                          Re: mdadm usage deloptes <deloptes@gmail.com> - 2021-01-02 12:50 +0100
            Re: mdadm usage "Thomas A. Anderson" <thomas.anderson@little-beak.com> - 2020-12-30 11:50 +0100
              Re: mdadm usage "Alexander V. Makartsev" <avbetev@gmail.com> - 2020-12-30 13:30 +0100
              Re: mdadm usage Dan Ritter <dsr@randomstring.org> - 2020-12-30 13:30 +0100
              Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 15:00 +0100
              Re: mdadm usage deloptes <deloptes@gmail.com> - 2020-12-30 22:10 +0100
                Re: mdadm usage Nicholas Geovanis <nickgeovanis@gmail.com> - 2020-12-31 00:00 +0100
          Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-30 09:10 +0100
        Re: mdadm usage Dan Ritter <dsr@randomstring.org> - 2020-12-30 04:00 +0100
    Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-29 14:20 +0100
      Re: mdadm usage mick crane <mick.crane@gmail.com> - 2020-12-29 16:40 +0100
        Re: mdadm usage "Alexander V. Makartsev" <avbetev@gmail.com> - 2020-12-29 20:40 +0100
        Re: mdadm usage Andy Smith <andy@strugglers.net> - 2020-12-30 14:40 +0100
          Re: mdadm usage The Wanderer <wanderer@fastmail.fm> - 2020-12-30 14:50 +0100
          Re: mdadm usage mick crane <mick.crane@gmail.com> - 2020-12-30 18:00 +0100
            Re: mdadm usage Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-30 19:40 +0100

Page 1 of 3  [1] 2 3  Next page →

#230062 — mdadm usage

Hello,

I have been "using" mdadm to run software raid1 (stripping) on a file
server i have been running.

None of the drives have failed, and I have even setup subsequent drives
in the same scenario.

It is only now that I wonder if I am even using RAID1 properly? In other
words, now that I try to access

data on these two original drives on another system, I am unable to. I
assume it's possible (albeit doesn't seem intuitively simple -- at least
for me), makes me wonder if it's enen supposed to be used like this.

I had assumed I could swap the drive out, and access the data (like a
normal drive), but that doesn't seem to be the case.


So, I ask a more precise question: Is mdadm designed to be used on other
system, and simply access data?

Maybe I just need two drives, and just do a cron job to rysnc to backup
once a week or something.

[toc] | [next] | [standalone]

#230063

	Hi.

On Tue, Dec 29, 2020 at 07:58:50AM +0100, Thomas A. Anderson wrote:
> I have been "using" mdadm to run software raid1 (stripping) on a file
> server i have been running.

RAID1 is mirroring. Stripping is RAID0.
RAID1 provides redundancy. RAID0 does not.


> It is only now that I wonder if I am even using RAID1 properly? In
> other words, now that I try to access data on these two original
> drives on another system, I am unable to. I assume it's possible
> (albeit doesn't seem intuitively simple -- at least for me), makes me
> wonder if it's enen supposed to be used like this.

It's possible for RAID1, it's impossible for RAID0. 
Which brings me to the question - cat /proc/mdstat . What does it show
for you?


> So, I ask a more precise question: Is mdadm designed to be used on other
> system, and simply access data?

As long as you have all the drives, any mdadm array should be able to
assemble and provide you the access to its contents on that other
system.
If you do not have all the drives but have RAID that provides redundancy
it's usually possible to convince mdadm to assemble a degraded array and
therefore access its contents.


> Maybe I just need two drives, and just do a cron job to rysnc to backup
> once a week or something.

RAID is not a substitute for a backup. Backup is not a substitute for
mirroring. One does not exclude another, so use both.

Reco

[toc] | [prev] | [next] | [standalone]

#230065

Reco wrote:

> 
>> Maybe I just need two drives, and just do a cron job to rysnc to backup
>> once a week or something.
> 
> RAID is not a substitute for a backup. Backup is not a substitute for
> mirroring. One does not exclude another, so use both.

I find borg backup worth looking in, especially because of the
deduplication.

[toc] | [prev] | [next] | [standalone]

#230064

Thomas A. Anderson composed on 2020-12-29 07:58 (UTC+0100):

> I have been "using" mdadm to run software raid1 (stripping) on a file
> server i have been running.

RAID 1 is two devices that are mirrors of each other, redundancy, with some loss
in speed. Loose one device, and you still have all your data.

RAID 0 is striping. One device failing means all data lost from two devices, but
twice as much space as RAID 1, and some extra speed.
-- 
Evolution as taught in public schools, like religion,
	is based on faith, not on science.

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

[toc] | [prev] | [next] | [standalone]

#230066

On a file server in a production environment I would prefer raid 6.

Am 29.12.20 um 08:45 schrieb Felix Miata:
> Thomas A. Anderson composed on 2020-12-29 07:58 (UTC+0100):
> 
>> I have been "using" mdadm to run software raid1 (stripping) on a file
>> server i have been running.
> 
> RAID 1 is two devices that are mirrors of each other, redundancy, with some loss
> in speed. Loose one device, and you still have all your data.
> 
> RAID 0 is striping. One device failing means all data lost from two devices, but
> twice as much space as RAID 1, and some extra speed.
> 

[toc] | [prev] | [next] | [standalone]

#230088

Thanks Reco, yeah that RAID6 looks pretty robust. I will read more about
it in the future. When I type cat /proc/mdstat, I get:

Personalities:

unused devices: <none>


Thanks Deloptes,  the Borg backup looks very promising and I think it
might actually best fit my needs. I will check it out!

Thanks Felix, for the quick reply. I actually know the difference --
just mental lapse, it was late, and I accidentlly said stripping, though
I meant mirroring (raid1).

I have been using it for years, and while not a bad "thing," in
retrospect, not sure it actually meant my critieria (eh, who knows,
maybe it did), but now I have a more clear use case, basically to have a
clean backup. I was using RAID1 as a "pseudo" backup, which I guess kind
of worked, but I should use a specific backup solution.

Thanks everyone.

Once I can get anything off one of these two drives, I will then switch
my current setup to 1 drive (8TB), with an attached 8TB drive that will
be be backup --weekly, or whatever.


On 29.12.20 09:36, basti wrote:
> On a file server in a production environment I would prefer raid 6.
>
> Am 29.12.20 um 08:45 schrieb Felix Miata:
>> Thomas A. Anderson composed on 2020-12-29 07:58 (UTC+0100):
>>
>>> I have been "using" mdadm to run software raid1 (stripping) on a file
>>> server i have been running.
>> RAID 1 is two devices that are mirrors of each other, redundancy, with some loss
>> in speed. Loose one device, and you still have all your data.
>>
>> RAID 0 is striping. One device failing means all data lost from two devices, but
>> twice as much space as RAID 1, and some extra speed.
>>

[toc] | [prev] | [next] | [standalone]

#230098

[Multipart message — attachments visible in raw view] — view raw

Thomas A. Anderson writes:

> Thanks Reco, yeah that RAID6 looks pretty robust. I will read more about
> it in the future. When I type cat /proc/mdstat, I get:
>
> Personalities:
>
> unused devices: <none>
>
>

Is that all there is? Because to me this means: RAID kernel driver loaded  
but no arrays running whatsoever. This state would also mean "zero  
redundancy"!

Here, it looks as follows:

~~~
$ cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : active (auto-read-only) raid1 nvme1n1p3[0] nvme0n1p3[1]
      127933440 blocks super 1.2 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md0 : active raid1 nvme1n1p2[0] nvme0n1p2[1]
      379868160 blocks super 1.2 [2/2] [UU]
      bitmap: 0/3 pages [0KB], 65536KB chunk

unused devices: <none>
~~~

Note the presence of different `md` devices and `UU` showing that two RAID1  
mirrors are active each with two disks (actually: partitions on the same two  
disks) present.

> Thanks Deloptes,  the Borg backup looks very promising and I think it
> might actually best fit my needs. I will check it out!

At the moment, borg seems to be among the best "complex" backup tools --  
i.e. tools that store data in their own format to achieve an additional  
benefit. If you like to pull a HDD and use it with another computer, a  
simpler approach like "rsync" or "tar" may also work well.

[...]

> Once I can get anything off one of these two drives, I will then switch
> my current setup to 1 drive (8TB), with an attached 8TB drive that will
> be be backup --weekly, or whatever.

Consider making this "daily" -- tools like borg allow you to keep copies of  
one week history without needing much additional disk space (depending on  
how much your data changes, that is).

[...]

In your original post you wrote:

> It is only now that I wonder if I am even using RAID1 properly? In other
> words, now that I try to access
>
> data on these two original drives on another system, I am unable to. I
> assume it's possible (albeit doesn't seem intuitively simple -- at least
> for me), makes me wonder if it's enen supposed to be used like this.
>
> I had assumed I could swap the drive out, and access the data (like a
> normal drive), but that doesn't seem to be the case.

What did you actually want to do? Just check whether the data is there? In  
these cases, a proper backup tool like Borg will allow that better. RAID is  
always picky about devices that are "temporarily absent" because what if  
data on just one of the devices changes? It could cause inconsistency and  
thus often requires explicit manual intervention to resolve (let the user  
decide which data to consider the "proper" copy). Hence, it is a sensible  
default for RAID tools to _not_ automatically enable/mount attached disks  
[unless all of the RAID's members are present].

If you are trying to move data between systems rather than just testing your  
backup, then there are many alternatives to consider (including, but not  
limited to rsync, network file systems, tar files).

HTH
Linux-Fan

öö

[toc] | [prev] | [next] | [standalone]

#230102

Thomas A. Anderson wrote:

> Once I can get anything off one of these two drives, I will then switch
> my current setup to 1 drive (8TB), with an attached 8TB drive that will
> be be backup --weekly, or whatever.

you can start one of the drives that was member of raid1 array on any
computer, just as Reco said by assembling the mdraid on that computer.

Check mdadm man page.

For example I attached a disk that was member of raid through a USB storage
box:

* Examine the RAID table

 mdadm --examine /dev/sdj
 /dev/sdj:
    MBR Magic : aa55
 Partition[0] :       997376 sectors at         2048 (type fd)
 Partition[1] :    156250112 sectors at       999424 (type fd)
 Partition[2] :   1796272130 sectors at    157251582 (type 05)

* Assemble and run the RAID array with one disk

 mdadm -A -R /dev/md0 /dev/sdj1
 mdadm: /dev/md0 has been started with 1 drive (out of 2).
 
 mdadm -A -R /dev/md1 /dev/sdj2
 mdadm: /dev/md1 has been started with 1 drive (out of 2).
 
 mdadm -A -R /dev/md2 /dev/sdj5
 mdadm: /dev/md2 has been started with 1 drive (out of 2).

Now I can do whatever I want with those partitions

[toc] | [prev] | [next] | [standalone]

#230104

On Wed, Dec 30, 2020 at 01:53:59AM +0100, deloptes wrote:
>you can start one of the drives that was member of raid1 array on any
>computer, just as Reco said by assembling the mdraid on that computer.

Just be very careful about ever putting both halves of the array on the 
same computer again, as one will overwrite the other, potentially 
automatically, and not necessarily in a direction you like.

[toc] | [prev] | [next] | [standalone]

#230114

Michael Stone wrote:

> Just be very careful about ever putting both halves of the array on the
> same computer again, as one will overwrite the other, potentially
> automatically, and not necessarily in a direction you like.

yes this is true. when you add the device you should mark it as faulty

[toc] | [prev] | [next] | [standalone]

#230121

On 2020-12-30 02:21, Michael Stone wrote:
> On Wed, Dec 30, 2020 at 01:53:59AM +0100, deloptes wrote:
>> you can start one of the drives that was member of raid1 array on any
>> computer, just as Reco said by assembling the mdraid on that computer.
>
> Just be very careful about ever putting both halves of the array on 
> the same computer again, as one will overwrite the other, potentially 
> automatically, and not necessarily in a direction you like.
>

I would hope that the most recently modified half of the array would be 
the one to overwrite the least recently modified one, so that a 
temporary absence of one disk which later comes back unmodified, will 
not destroy data.

Is that how it works?

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#230125

Hello,

On Wed, Dec 30, 2020 at 02:38:46PM +0100, Jesper Dybdal wrote:
> I would hope that the most recently modified half of the array would be the
> one to overwrite the least recently modified one, so that a temporary
> absence of one disk which later comes back unmodified, will not destroy
> data.

Consider what happens if you take an mdadm RAID-1 member and put it
in another machine, mount it and then start writing to it. The
events count of the device will increase with each write.

If you then take that device and put it back in the original
machine, and it has a higher event count than the device in the
machine already, on next assemble mdadm will overwrite the device
that has the lower event count.

You can see the event count with:

# mdadm --examine /dev/sda1 # or whatever the member device is

So yes in one way your idea that the most recently modified half is
the one chosen could be said to be correct, if by "most recently
modified" you actually mean "most number of events".

As you were thinking, it is pretty safe to do if you never write to
the device you take out.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#230251

On 2020-12-30 14:58, Andy Smith wrote:
> You can see the event count with:
>
> # mdadm --examine /dev/sda1 # or whatever the member device is
>
> So yes in one way your idea that the most recently modified half is
> the one chosen could be said to be correct, if by "most recently
> modified" you actually mean "most number of events".
>
> As you were thinking, it is pretty safe to do if you never write to
> the device you take out.
>
Thanks for introducing me to the "event count" concept.  But when I look 
at the event counts of my RAID1 disks, I get confused: the event count 
seems to not increase in normal use, except that once in a while it 
temporarily increments by one and then decrements back again a moment later:

root@nuser:~# while :; do mdadm --examine /dev/sda2 |grep "Events :"; 
sleep 3; done
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17116
          Events : 17117
          Events : 17116
          Events : 17116
          Events : 17116

The value has been 17116 or 17117 for several days.  This is the root 
partition and it is regularly written to (that partition has a 
mailserver queue directory and /var/log and ...).

So if it really uses that count to determine synchronization, then I 
don't see how it can work.

On the other hand, the timestamp value is updated "all the time".

-- 
Jesper Dybdal
https://www.dybdal.dk

[toc] | [prev] | [next] | [standalone]

#230126

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 30, 2020, 7:39 AM Jesper Dybdal <jd-debian-user@dybdal.dk>
wrote:

> I would hope that the most recently modified half of the array would be
> the one to overwrite the least recently modified one, so that a
> temporary absence of one disk which later comes back unmodified, will
> not destroy data.
>
> Is that how it works?
>

You would hope that it works that way. Trouble is, you can't necesssrily
tell how far the failed drive got in the last write to it. And cause
failure occurred, mdadm can't always tell either. In addition, unfixable
corruption may have taken place in the filesystem above that, such that
even a succesful mdadm recovery still doesn't get your data back. So the
backup on separate media is crucial.

Some places I've worked use mdadm only for RAID performance reasons. But
any failure recovery is a restore from off site backup. They don't even try
RAID recovery. Or as I have done in the past, the other half of the RAID 1
is put directly into use, the failed drive is simply removed and destroyed,
then replaced with a brand new drive and re-mirrored. If you have hundreds
or thousands of servers, weelll..... there's another good argument for
virtualisation. Said your boss :-)

-- 
> Jesper Dybdal
> https://www.dybdal.dk
>
>

[toc] | [prev] | [next] | [standalone]

#230127

[Multipart message — attachments visible in raw view] — view raw

On Wed, Dec 30, 2020, 8:03 AM Nicholas Geovanis <nickgeovanis@gmail.com>
wrote:

>
>
> On Wed, Dec 30, 2020, 7:39 AM Jesper Dybdal <jd-debian-user@dybdal.dk>
> wrote:
>
>> I would hope that the most recently modified half of the array would be
>> the one to overwrite the least recently modified one, so that a
>> temporary absence of one disk which later comes back unmodified, will
>> not destroy data.
>>
>> Is that how it works?
>>
>
> .....
> ....the failed drive is simply removed and destroyed, then replaced with a
> brand new drive and re-mirrored. If you have hundreds or thousands of
> servers, weelll..... there's another good argument for virtualisation. Said
> your boss :-)
>

And also an argument in favor of using only SSD, now that we're past the
first couple generations of it which were quite unreliable.

-- 
>> Jesper Dybdal
>> https://www.dybdal.dk
>>
>>

[toc] | [prev] | [next] | [standalone]

#230144

Nicholas Geovanis wrote:

> And also an argument in favor of using only SSD, now that we're past the
> first couple generations of it which were quite unreliable.

It depends. For example on the machine at home with LSI adapter that
provides the speed of SATA II I do not see any benefit of using SSD except
power saving, but when you calculate the power saved it does not cover the
extra cost of the SSD. I use the WD RED 3.5" which is forced into SATA 2.
It is simple mathematics.

[toc] | [prev] | [next] | [standalone]

#230148

On Wed, Dec 30, 2020 at 09:44:09PM +0100, deloptes wrote:
>It depends. For example on the machine at home with LSI adapter that
>provides the speed of SATA II I do not see any benefit of using SSD except
>power saving

The improvement in seek times typically makes for a dramatic improvement 
in usability and user experience, regardless of maximum transfer rate. 
Replacing an SSD with an HD will usually breathe new life into an old 
system; people tend to dramatically underestimate how much I/O wait 
impacts performance. If you've got enough RAM to cache the entire 
working disk then this will be much less noticeable, except on boot, but 
that's usually not the case on desktop systems.

[toc] | [prev] | [next] | [standalone]

#230149

Michael Stone wrote:

> The improvement in seek times typically makes for a dramatic improvement
> in usability and user experience, regardless of maximum transfer rate.
> Replacing an SSD with an HD will usually breathe new life into an old
> system; people tend to dramatically underestimate how much I/O wait
> impacts performance. If you've got enough RAM to cache the entire
> working disk then this will be much less noticeable, except on boot, but
> that's usually not the case on desktop systems.

I was actually thinking of replacing the rotating disks yesterday at least
for the system and build environment as it has a lot of IO - I guess your
argument counts, so may be I will reconsider replacing them.

Can someone recommend server or NAS grade (SATA) SSD - a reliable one for
RAID use?

[toc] | [prev] | [next] | [standalone]

#230152

Hello,

On Wed, Dec 30, 2020 at 11:14:37PM +0100, deloptes wrote:
> Can someone recommend server or NAS grade (SATA) SSD - a reliable one for
> RAID use?

I suggest checking smartctl values on your existing device to see
how much data you write in a week or so, then convert that to the
matching units (Drive Writes Per Day or TeraBytes Written) shown in
SSD specs so you can work out what you require for however many
years of operation you expect.

Then make sure it has power loss protection.

I would expect any major brand that passes those requirements to be
fine for your use case.

Personally for SATA interface I like Samsung's SM883 or PM883 (3
DWPD vs 1.3 DWPD assuming no over provisioning), but certainly there
are much cheaper options that are still good.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#230155

On Wednesday, December 30, 2020 06:20:09 PM Andy Smith wrote:
> On Wed, Dec 30, 2020 at 11:14:37PM +0100, deloptes wrote:
> > Can someone recommend server or NAS grade (SATA) SSD - a reliable one for
> > RAID use?

...

> Then make sure it has power loss protection.

What do you mean by power loss protection -- do you mean, for example, that 
the host computer is on a UPS, or is that a feature of some SSDs?

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web