Re: Have suggestions for a "roll your own file server"?

[Bruce Labitt]

fstab updated.  Just needed to use UUID=, not PARTUUID.  I do notice 
significantly long boot times now, guess it takes a while to get the 
RAID1 up.  Used to take 5 seconds to be available to ssh into, now takes 
about 45 seconds to a minute.

I think I'd like the server to initiate the backup.  So, first, I think 
I should set up ssh keys.  So the client/server (who's on first!) 
confusion rears it's ugly head.  For the server (the storage center) to 
contact the client (one of several laptops), I need to use the client's 
public key?  So I need to create the client's key pair?  Once I have the 
client's public key I use the ssh-copy-id command from the client to the 
server?

Now if I want no passwords sent what do I do?  (Just keys).  I didn't 
quite understand the example on 
https://www.howtogeek.com/424510/how-to-create-and-install-ssh-keys-from-the-linux-shell/
 
It seems one can have the passphrase last a session, how to get it to 
remember to use the clients' keys in "perpetuity"?  If there's a 
problem, how to revoke the keys?

Have some questions on rsync --backup option, is there a way to have 
like a rotating backup, say a weeks worth?  I don't understand the 
difference between --backup and just using -avr, what is the advantage 
of --backup?  The rsync man file was not clear to me (today).

Thanks

Sorry, had to truncate the message - gnhlug server complained about it 
being over 50KB




___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Have suggestions for a "roll your own file server"?

[John Abreau]

I've been running CentOS NAS servers for the past 15 years. I can usually
find a decent rackmount server on eBay for around $99 that I imagine was
probably used in the financial industry for a year or so and then turned
over to a liquidator for disposal. I then load the drive bays with SATA
drives I order from Amazon, install CentOS, and configure the machine as an
NFS server.

I configure the drives in RAID-1 pairs when installing the OS. On the first
pair I create a regular partition for /boot and an LVM pv volume for the
rest of the disk, and for the remaining drive pairs I make the entire disk
a pv volume. I install a cron job that regularly checks the drives and
sends me email alerts if it detects any problems, so I can replace failing
drives in a timely manner.

I've never calculated how it impacts my electric bill, and it's possible a
low-power server box may be more cost effective overall, but my electric
bill hasn't been noticeably bad.


On Thu, May 27, 2021 at 2:08 PM Tom Buskey  wrote:

> In my mind, the client is what gets backed up.  The host stores it.
> I hadn't considered ransomware.  I think ZFS snapshots on the host would
> work well w/o using much more space.
>
> @Bruce Labitt  I did Solaris up until just after the
> Oracle takeover (Solaris 11 even!), including some at home.  I've forgotten
> just about everything about Solaris that isn't in Linux.  If you're not
> using it, you lose it.
>
> On Wed, May 26, 2021 at 4:58 PM Bruce Labitt  wrote:
>
>> Thanks for the compliment.  Put a bit of work into it.  Self taught hobby
>> machinist.  Self taught Linux as well.  Only have had machines for 18
>> months.  Embarrassed to say how long I've been using Linux, as I keep on
>> asking basic questions.
>>
>> On Wed, May 26, 2021, 12:14 PM Tom Buskey  wrote:
>>
>>> My Fedora /etc/fstab has spaces
>>> UUID=54103729-6e0a-4345-a2b8-8b8cded29ee1 /boot   ext4
>>>  defaults1 2
>>>
>>> I've had clients initiate rsync for security.  I think the client
>>> initiation would offload the rsync compute from the server.
>>> For a home server, it's nice to just monitor the server instead of
>>> multiple clients.
>>>
>>> Nice buiild
>>>
>>> On Wed, May 26, 2021 at 11:00 AM Bruce Labitt <
>>> bruce.lab...@myfairpoint.net> wrote:
>>>
 Finally back to this.  Built a stack of metal plates that house my
 RPI4, a boot SSD, a 1TB RAID1 array, and both active and passive USB3
 hubs.  Machined parts so everything is bolted and clamped down.  Have a PWM
 fan that cools the RPI4 proportional to load that runs under systemd.
 System boots from SSD.  (No SD card.)  It's kind of a brick sh!thouse, but
 it's sturdy.  Have created the RAID1 device - or it will be finished in 45
 minutes.  It is still syncing.

 Now I'd like to add the md0 device to /etc/fstab.  The example I see is
 with the device name.  From
 https://www.tecmint.com/create-raid1-in-linux/
 /dev/md0/mnt/raid1ext4defaults0 0

 I've read it is better to use the UUID.  Is the following the correct
 syntax?

 PARTUUID=my_complete_md0_UUID  /mnt/raid1ext4defaults  0 0

 where my_complete_md0_UUID comes from
 $ lsblk -o UUID /dev/md0

 Does one need to use tabs in fstab, or are spaces ok?

 Once I figure this out - I have to figure out some rsync magic.  Is it
 better for the server to initiate the rsync, or the remote devices?

 After all this I have to make another one.  That shouldn't take as long
 as the first time!  For some pictures of the hardware build see
 https://www.hobby-machinist.com/threads/an-rpi4-based-file-server.92273/#post-846939



 On 3/10/21 8:49 PM, Bruce Labitt wrote:

 I'll take a look at that.  Thanks for the link.

 On Wed, Mar 10, 2021 at 8:15 PM Marc Nozell (m...@nozell.com) <
 noz...@gmail.com> wrote:

> Just to put a plug in for a colleague's work:
> https://perfectmediaserver.com/It covers everything from disk
> purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).
>
> He also hosts a podcast that folks here may find interesting:
> https://selfhosted.show/
>
> -marc
>
> On Wed, Mar 10, 2021 at 8:08 PM  wrote:
>
>> OK:
>>
>> s/RPi4/some-other-cheap-computer-with-USB-3.x>/g
>>
>> Unless you build multiple Ethernet or WiFi or LTE modem connections
>> your networking will still be the slowest thing.
>>
>> You do not need huge amounts of CPU power, or huge amounts of RAM.
>>
>> My basic point is that if you stick with simple RAID (like mirroring)
>> but also set up a unit that is remote from your own home you could 
>> protect
>> your own data from fire, flood and theft to a reasonable level and even
>> protect your friend's data by backing up their data to your device.
>>
>> Add snapshots as suggested by Tom 

Re: Have suggestions for a "roll your own file server"?

[Tom Buskey]

In my mind, the client is what gets backed up.  The host stores it.
I hadn't considered ransomware.  I think ZFS snapshots on the host would
work well w/o using much more space.

@Bruce Labitt  I did Solaris up until just after the
Oracle takeover (Solaris 11 even!), including some at home.  I've forgotten
just about everything about Solaris that isn't in Linux.  If you're not
using it, you lose it.

On Wed, May 26, 2021 at 4:58 PM Bruce Labitt  wrote:

> Thanks for the compliment.  Put a bit of work into it.  Self taught hobby
> machinist.  Self taught Linux as well.  Only have had machines for 18
> months.  Embarrassed to say how long I've been using Linux, as I keep on
> asking basic questions.
>
> On Wed, May 26, 2021, 12:14 PM Tom Buskey  wrote:
>
>> My Fedora /etc/fstab has spaces
>> UUID=54103729-6e0a-4345-a2b8-8b8cded29ee1 /boot   ext4
>>  defaults1 2
>>
>> I've had clients initiate rsync for security.  I think the client
>> initiation would offload the rsync compute from the server.
>> For a home server, it's nice to just monitor the server instead of
>> multiple clients.
>>
>> Nice buiild
>>
>> On Wed, May 26, 2021 at 11:00 AM Bruce Labitt <
>> bruce.lab...@myfairpoint.net> wrote:
>>
>>> Finally back to this.  Built a stack of metal plates that house my RPI4,
>>> a boot SSD, a 1TB RAID1 array, and both active and passive USB3 hubs.
>>> Machined parts so everything is bolted and clamped down.  Have a PWM fan
>>> that cools the RPI4 proportional to load that runs under systemd.  System
>>> boots from SSD.  (No SD card.)  It's kind of a brick sh!thouse, but it's
>>> sturdy.  Have created the RAID1 device - or it will be finished in 45
>>> minutes.  It is still syncing.
>>>
>>> Now I'd like to add the md0 device to /etc/fstab.  The example I see is
>>> with the device name.  From
>>> https://www.tecmint.com/create-raid1-in-linux/
>>> /dev/md0/mnt/raid1ext4defaults0 0
>>>
>>> I've read it is better to use the UUID.  Is the following the correct
>>> syntax?
>>>
>>> PARTUUID=my_complete_md0_UUID  /mnt/raid1ext4defaults  0 0
>>>
>>> where my_complete_md0_UUID comes from
>>> $ lsblk -o UUID /dev/md0
>>>
>>> Does one need to use tabs in fstab, or are spaces ok?
>>>
>>> Once I figure this out - I have to figure out some rsync magic.  Is it
>>> better for the server to initiate the rsync, or the remote devices?
>>>
>>> After all this I have to make another one.  That shouldn't take as long
>>> as the first time!  For some pictures of the hardware build see
>>> https://www.hobby-machinist.com/threads/an-rpi4-based-file-server.92273/#post-846939
>>>
>>>
>>>
>>> On 3/10/21 8:49 PM, Bruce Labitt wrote:
>>>
>>> I'll take a look at that.  Thanks for the link.
>>>
>>> On Wed, Mar 10, 2021 at 8:15 PM Marc Nozell (m...@nozell.com) <
>>> noz...@gmail.com> wrote:
>>>
 Just to put a plug in for a colleague's work:
 https://perfectmediaserver.com/It covers everything from disk
 purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).

 He also hosts a podcast that folks here may find interesting:
 https://selfhosted.show/

 -marc

 On Wed, Mar 10, 2021 at 8:08 PM  wrote:

> OK:
>
> s/RPi4/some-other-cheap-computer-with-USB-3.x>/g
>
> Unless you build multiple Ethernet or WiFi or LTE modem connections
> your networking will still be the slowest thing.
>
> You do not need huge amounts of CPU power, or huge amounts of RAM.
>
> My basic point is that if you stick with simple RAID (like mirroring)
> but also set up a unit that is remote from your own home you could protect
> your own data from fire, flood and theft to a reasonable level and even
> protect your friend's data by backing up their data to your device.
>
> Add snapshots as suggested by Tom Buskey,perhaps encryption of file
> systems and data-streams and you can have a rather simple, server where 
> you
> learn a lot by planning it out and setting it up rather than buying an 
> "off
> the shelf" solution or simply using a "web backup".
>
> And good catch on the USB power supply.
>
> md
> > On 03/10/2021 6:53 PM Joshua Judson Rosen 
> wrote:
> >
> >
> > I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+
> there are... problems, e.g.:
> >
> > Beware of USB on the raspi: there are some bugs in the silicon that
> pretty severely
> > cripple performance when multiple `bulk' devices are used at
> simultaneously,
> > sometimes to the point of making it unusable (e.g. if you want to
> use a better Wi-Fi
> > adapter/antenna than the one built onto the board, and connect an
> LTE modem so that
> > your raspi roam onto that if Wi-Fi becomes unavailable, throughput
> on whichever of those
> > interfaces you're actually using can become abysmal). IIRC the issue
> is basically
> > that the 

Re: Have suggestions for a "roll your own file server"?

[Bruce Labitt]

Thanks for the compliment.  Put a bit of work into it.  Self taught hobby
machinist.  Self taught Linux as well.  Only have had machines for 18
months.  Embarrassed to say how long I've been using Linux, as I keep on
asking basic questions.

On Wed, May 26, 2021, 12:14 PM Tom Buskey  wrote:

> My Fedora /etc/fstab has spaces
> UUID=54103729-6e0a-4345-a2b8-8b8cded29ee1 /boot   ext4
>  defaults1 2
>
> I've had clients initiate rsync for security.  I think the client
> initiation would offload the rsync compute from the server.
> For a home server, it's nice to just monitor the server instead of
> multiple clients.
>
> Nice buiild
>
> On Wed, May 26, 2021 at 11:00 AM Bruce Labitt <
> bruce.lab...@myfairpoint.net> wrote:
>
>> Finally back to this.  Built a stack of metal plates that house my RPI4,
>> a boot SSD, a 1TB RAID1 array, and both active and passive USB3 hubs.
>> Machined parts so everything is bolted and clamped down.  Have a PWM fan
>> that cools the RPI4 proportional to load that runs under systemd.  System
>> boots from SSD.  (No SD card.)  It's kind of a brick sh!thouse, but it's
>> sturdy.  Have created the RAID1 device - or it will be finished in 45
>> minutes.  It is still syncing.
>>
>> Now I'd like to add the md0 device to /etc/fstab.  The example I see is
>> with the device name.  From
>> https://www.tecmint.com/create-raid1-in-linux/
>> /dev/md0/mnt/raid1ext4defaults0 0
>>
>> I've read it is better to use the UUID.  Is the following the correct
>> syntax?
>>
>> PARTUUID=my_complete_md0_UUID  /mnt/raid1ext4defaults  0 0
>>
>> where my_complete_md0_UUID comes from
>> $ lsblk -o UUID /dev/md0
>>
>> Does one need to use tabs in fstab, or are spaces ok?
>>
>> Once I figure this out - I have to figure out some rsync magic.  Is it
>> better for the server to initiate the rsync, or the remote devices?
>>
>> After all this I have to make another one.  That shouldn't take as long
>> as the first time!  For some pictures of the hardware build see
>> https://www.hobby-machinist.com/threads/an-rpi4-based-file-server.92273/#post-846939
>>
>>
>>
>> On 3/10/21 8:49 PM, Bruce Labitt wrote:
>>
>> I'll take a look at that.  Thanks for the link.
>>
>> On Wed, Mar 10, 2021 at 8:15 PM Marc Nozell (m...@nozell.com) <
>> noz...@gmail.com> wrote:
>>
>>> Just to put a plug in for a colleague's work:
>>> https://perfectmediaserver.com/It covers everything from disk
>>> purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).
>>>
>>> He also hosts a podcast that folks here may find interesting:
>>> https://selfhosted.show/
>>>
>>> -marc
>>>
>>> On Wed, Mar 10, 2021 at 8:08 PM  wrote:
>>>
 OK:

 s/RPi4/some-other-cheap-computer-with-USB-3.x>/g

 Unless you build multiple Ethernet or WiFi or LTE modem connections
 your networking will still be the slowest thing.

 You do not need huge amounts of CPU power, or huge amounts of RAM.

 My basic point is that if you stick with simple RAID (like mirroring)
 but also set up a unit that is remote from your own home you could protect
 your own data from fire, flood and theft to a reasonable level and even
 protect your friend's data by backing up their data to your device.

 Add snapshots as suggested by Tom Buskey,perhaps encryption of file
 systems and data-streams and you can have a rather simple, server where you
 learn a lot by planning it out and setting it up rather than buying an "off
 the shelf" solution or simply using a "web backup".

 And good catch on the USB power supply.

 md
 > On 03/10/2021 6:53 PM Joshua Judson Rosen 
 wrote:
 >
 >
 > I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there
 are... problems, e.g.:
 >
 > Beware of USB on the raspi: there are some bugs in the silicon that
 pretty severely
 > cripple performance when multiple `bulk' devices are used at
 simultaneously,
 > sometimes to the point of making it unusable (e.g. if you want to use
 a better Wi-Fi
 > adapter/antenna than the one built onto the board, and connect an LTE
 modem so that
 > your raspi roam onto that if Wi-Fi becomes unavailable, throughput on
 whichever of those
 > interfaces you're actually using can become abysmal). IIRC the issue
 is basically
 > that the number of USB endpoints that can be assigned interrupts by
 the raspi controller
 > is _incredibly small_; and it's common for high-throughput devices to
 have multiple endpoints per device--
 > sometimes even one USB device will have more endpoints that the raspi
 USB controller can handle.
 >
 > Also, `network fileserver with USB-attached hard drives' is kind of
 the `peak unfitness'
 > for the raspberry pi. Specifically if you've got it attached to
 ethernet,
 > the ethernet is attached through the same slow-ish USB bus as your
 

Re: Have suggestions for a "roll your own file server"?

[Ken D'Ambrosio]

On 2021-05-26 12:13, Tom Buskey wrote:


My Fedora /etc/fstab has spaces
UUID=54103729-6e0a-4345-a2b8-8b8cded29ee1 /boot   ext4  
  defaults1 2


I've had clients initiate rsync for security.  I think the client 
initiation would offload the rsync compute from the server.
For a home server, it's nice to just monitor the server instead of 
multiple clients.


I'm not sure which you guys are considering client, and which server.  I 
like to initiate from the thing I'm backing up *to*; that way, if the 
host being backed up is compromised, they won't have direct access to 
the backups, themselves, which, in the days of ransomware, seems like a 
valid concern.  (I'd also lock down the host doing the backups pretty 
tightly.)


$.02,

-Ken


Nice buiild

On Wed, May 26, 2021 at 11:00 AM Bruce Labitt 
 wrote:


Finally back to this.  Built a stack of metal plates that house my 
RPI4, a boot SSD, a 1TB RAID1 array, and both active and passive USB3 
hubs.  Machined parts so everything is bolted and clamped down.  Have a 
PWM fan that cools the RPI4 proportional to load that runs under 
systemd.  System boots from SSD.  (No SD card.)  It's kind of a brick 
sh!thouse, but it's sturdy.  Have created the RAID1 device - or it will 
be finished in 45 minutes.  It is still syncing.


Now I'd like to add the md0 device to /etc/fstab.  The example I see is 
with the device name.  From 
https://www.tecmint.com/create-raid1-in-linux/

/dev/md0/mnt/raid1ext4defaults0 0

I've read it is better to use the UUID.  Is the following the correct 
syntax?


PARTUUID=my_complete_md0_UUID  /mnt/raid1ext4defaults  0 0

where my_complete_md0_UUID comes from
$ lsblk -o UUID /dev/md0

Does one need to use tabs in fstab, or are spaces ok?

Once I figure this out - I have to figure out some rsync magic.  Is it 
better for the server to initiate the rsync, or the remote devices?


After all this I have to make another one.  That shouldn't take as long 
as the first time!  For some pictures of the hardware build see 
https://www.hobby-machinist.com/threads/an-rpi4-based-file-server.92273/#post-846939


On 3/10/21 8:49 PM, Bruce Labitt wrote:
I'll take a look at that.  Thanks for the link.

On Wed, Mar 10, 2021 at 8:15 PM Marc Nozell (m...@nozell.com) 
 wrote:
Just to put a plug in for a colleague's work: 
https://perfectmediaserver.com/It covers everything from disk 
purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).


He also hosts a podcast that folks here may find interesting: 
https://selfhosted.show/


-marc

On Wed, Mar 10, 2021 at 8:08 PM  wrote: OK:

s/RPi4/some-other-cheap-computer-with-USB-3.x>/g

Unless you build multiple Ethernet or WiFi or LTE modem connections 
your networking will still be the slowest thing.


You do not need huge amounts of CPU power, or huge amounts of RAM.

My basic point is that if you stick with simple RAID (like mirroring) 
but also set up a unit that is remote from your own home you could 
protect your own data from fire, flood and theft to a reasonable level 
and even protect your friend's data by backing up their data to your 
device.


Add snapshots as suggested by Tom Buskey,perhaps encryption of file 
systems and data-streams and you can have a rather simple, server where 
you learn a lot by planning it out and setting it up rather than buying 
an "off the shelf" solution or simply using a "web backup".


And good catch on the USB power supply.

md
On 03/10/2021 6:53 PM Joshua Judson Rosen  
wrote:



I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there 
are... problems, e.g.:


Beware of USB on the raspi: there are some bugs in the silicon that 
pretty severely
cripple performance when multiple `bulk' devices are used at 
simultaneously,
sometimes to the point of making it unusable (e.g. if you want to use 
a better Wi-Fi
adapter/antenna than the one built onto the board, and connect an LTE 
modem so that
your raspi roam onto that if Wi-Fi becomes unavailable, throughput on 
whichever of those
interfaces you're actually using can become abysmal). IIRC the issue 
is basically
that the number of USB endpoints that can be assigned interrupts by 
the raspi controller
is _incredibly small_; and it's common for high-throughput devices to 
have multiple endpoints per device--
sometimes even one USB device will have more endpoints that the raspi 
USB controller can handle.


Also, `network fileserver with USB-attached hard drives' is kind of 
the `peak unfitness'
for the raspberry pi. Specifically if you've got it attached to 
ethernet,
the ethernet is attached through the same slow-ish USB bus as your 
HDDs.


(the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard 
Wi-Fi, I guess you might also

be able to make your µSD card faster...)

ALSO: you'll really want to use an externally-powered USB hub for USB 
devices
that are not totally trivial, because the raspi's µUSB power supply is 
already
strained... (and 

Re: Have suggestions for a "roll your own file server"?

[Tom Buskey]

My Fedora /etc/fstab has spaces
UUID=54103729-6e0a-4345-a2b8-8b8cded29ee1 /boot   ext4
 defaults1 2

I've had clients initiate rsync for security.  I think the client
initiation would offload the rsync compute from the server.
For a home server, it's nice to just monitor the server instead of multiple
clients.

Nice buiild

On Wed, May 26, 2021 at 11:00 AM Bruce Labitt 
wrote:

> Finally back to this.  Built a stack of metal plates that house my RPI4, a
> boot SSD, a 1TB RAID1 array, and both active and passive USB3 hubs.
> Machined parts so everything is bolted and clamped down.  Have a PWM fan
> that cools the RPI4 proportional to load that runs under systemd.  System
> boots from SSD.  (No SD card.)  It's kind of a brick sh!thouse, but it's
> sturdy.  Have created the RAID1 device - or it will be finished in 45
> minutes.  It is still syncing.
>
> Now I'd like to add the md0 device to /etc/fstab.  The example I see is
> with the device name.  From https://www.tecmint.com/create-raid1-in-linux/
> /dev/md0/mnt/raid1ext4defaults0 0
>
> I've read it is better to use the UUID.  Is the following the correct
> syntax?
>
> PARTUUID=my_complete_md0_UUID  /mnt/raid1ext4defaults  0 0
>
> where my_complete_md0_UUID comes from
> $ lsblk -o UUID /dev/md0
>
> Does one need to use tabs in fstab, or are spaces ok?
>
> Once I figure this out - I have to figure out some rsync magic.  Is it
> better for the server to initiate the rsync, or the remote devices?
>
> After all this I have to make another one.  That shouldn't take as long as
> the first time!  For some pictures of the hardware build see
> https://www.hobby-machinist.com/threads/an-rpi4-based-file-server.92273/#post-846939
>
>
>
> On 3/10/21 8:49 PM, Bruce Labitt wrote:
>
> I'll take a look at that.  Thanks for the link.
>
> On Wed, Mar 10, 2021 at 8:15 PM Marc Nozell (m...@nozell.com) <
> noz...@gmail.com> wrote:
>
>> Just to put a plug in for a colleague's work:
>> https://perfectmediaserver.com/It covers everything from disk
>> purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).
>>
>> He also hosts a podcast that folks here may find interesting:
>> https://selfhosted.show/
>>
>> -marc
>>
>> On Wed, Mar 10, 2021 at 8:08 PM  wrote:
>>
>>> OK:
>>>
>>> s/RPi4/some-other-cheap-computer-with-USB-3.x>/g
>>>
>>> Unless you build multiple Ethernet or WiFi or LTE modem connections your
>>> networking will still be the slowest thing.
>>>
>>> You do not need huge amounts of CPU power, or huge amounts of RAM.
>>>
>>> My basic point is that if you stick with simple RAID (like mirroring)
>>> but also set up a unit that is remote from your own home you could protect
>>> your own data from fire, flood and theft to a reasonable level and even
>>> protect your friend's data by backing up their data to your device.
>>>
>>> Add snapshots as suggested by Tom Buskey,perhaps encryption of file
>>> systems and data-streams and you can have a rather simple, server where you
>>> learn a lot by planning it out and setting it up rather than buying an "off
>>> the shelf" solution or simply using a "web backup".
>>>
>>> And good catch on the USB power supply.
>>>
>>> md
>>> > On 03/10/2021 6:53 PM Joshua Judson Rosen 
>>> wrote:
>>> >
>>> >
>>> > I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there
>>> are... problems, e.g.:
>>> >
>>> > Beware of USB on the raspi: there are some bugs in the silicon that
>>> pretty severely
>>> > cripple performance when multiple `bulk' devices are used at
>>> simultaneously,
>>> > sometimes to the point of making it unusable (e.g. if you want to use
>>> a better Wi-Fi
>>> > adapter/antenna than the one built onto the board, and connect an LTE
>>> modem so that
>>> > your raspi roam onto that if Wi-Fi becomes unavailable, throughput on
>>> whichever of those
>>> > interfaces you're actually using can become abysmal). IIRC the issue
>>> is basically
>>> > that the number of USB endpoints that can be assigned interrupts by
>>> the raspi controller
>>> > is _incredibly small_; and it's common for high-throughput devices to
>>> have multiple endpoints per device--
>>> > sometimes even one USB device will have more endpoints that the raspi
>>> USB controller can handle.
>>> >
>>> > Also, `network fileserver with USB-attached hard drives' is kind of
>>> the `peak unfitness'
>>> > for the raspberry pi. Specifically if you've got it attached to
>>> ethernet,
>>> > the ethernet is attached through the same slow-ish USB bus as your
>>> HDDs.
>>> >
>>> > (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard
>>> Wi-Fi, I guess you might also
>>> >  be able to make your µSD card faster...)
>>> >
>>> > ALSO: you'll really want to use an externally-powered USB hub for USB
>>> devices
>>> > that are not totally trivial, because the raspi's µUSB power supply is
>>> already
>>> > strained... (and if you're trying to power your raspi from some random
>>> USB power supply,
>>> > 

Re: Have suggestions for a "roll your own file server"?

[Bruce Labitt]

Finally back to this.  Built a stack of metal plates that house my RPI4, 
a boot SSD, a 1TB RAID1 array, and both active and passive USB3 hubs.  
Machined parts so everything is bolted and clamped down.  Have a PWM fan 
that cools the RPI4 proportional to load that runs under systemd.  
System boots from SSD.  (No SD card.)  It's kind of a brick sh!thouse, 
but it's sturdy.  Have created the RAID1 device - or it will be finished 
in 45 minutes.  It is still syncing.


Now I'd like to add the md0 device to /etc/fstab.  The example I see is 
with the device name.  From https://www.tecmint.com/create-raid1-in-linux/

/dev/md0    /mnt/raid1    ext4 defaults    0 0

I've read it is better to use the UUID.  Is the following the correct 
syntax?


PARTUUID=my_complete_md0_UUID /mnt/raid1    ext4    defaults  0 0

where my_complete_md0_UUID comes from
$ lsblk -o UUID /dev/md0

Does one need to use tabs in fstab, or are spaces ok?

Once I figure this out - I have to figure out some rsync magic.  Is it 
better for the server to initiate the rsync, or the remote devices?


After all this I have to make another one.  That shouldn't take as long 
as the first time!  For some pictures of the hardware build see 
https://www.hobby-machinist.com/threads/an-rpi4-based-file-server.92273/#post-846939




On 3/10/21 8:49 PM, Bruce Labitt wrote:

I'll take a look at that.  Thanks for the link.

On Wed, Mar 10, 2021 at 8:15 PM Marc Nozell (m...@nozell.com 
) mailto:noz...@gmail.com>> 
wrote:


Just to put a plug in for a colleague's work:
https://perfectmediaserver.com/ 
  It covers everything from disk purchasing strategies, burn-in,
filesystems (ZFS, SnapRAID, etc).

He also hosts a podcast that folks here may find interesting:
https://selfhosted.show/ 

-marc

On Wed, Mar 10, 2021 at 8:08 PM mailto:jonhal...@comcast.net>> wrote:

OK:

s/RPi4/some-other-cheap-computer-with-USB-3.x>/g

Unless you build multiple Ethernet or WiFi or LTE modem
connections your networking will still be the slowest thing.

You do not need huge amounts of CPU power, or huge amounts of RAM.

My basic point is that if you stick with simple RAID (like
mirroring) but also set up a unit that is remote from your own
home you could protect your own data from fire, flood and
theft to a reasonable level and even protect your friend's
data by backing up their data to your device.

Add snapshots as suggested by Tom Buskey,perhaps encryption of
file systems and data-streams and you can have a rather
simple, server where you learn a lot by planning it out and
setting it up rather than buying an "off the shelf" solution
or simply using a "web backup".

And good catch on the USB power supply.

md
> On 03/10/2021 6:53 PM Joshua Judson Rosen
mailto:roz...@hackerposse.com>> wrote:
>
>
> I'm not sure about the Raspberry Pi 4, but up thru the raspi
3+ there are... problems, e.g.:
>
> Beware of USB on the raspi: there are some bugs in the
silicon that pretty severely
> cripple performance when multiple `bulk' devices are used at
simultaneously,
> sometimes to the point of making it unusable (e.g. if you
want to use a better Wi-Fi
> adapter/antenna than the one built onto the board, and
connect an LTE modem so that
> your raspi roam onto that if Wi-Fi becomes unavailable,
throughput on whichever of those
> interfaces you're actually using can become abysmal). IIRC
the issue is basically
> that the number of USB endpoints that can be assigned
interrupts by the raspi controller
> is _incredibly small_; and it's common for high-throughput
devices to have multiple endpoints per device--
> sometimes even one USB device will have more endpoints that
the raspi USB controller can handle.
>
> Also, `network fileserver with USB-attached hard drives' is
kind of the `peak unfitness'
> for the raspberry pi. Specifically if you've got it attached
to ethernet,
> the ethernet is attached through the same slow-ish USB bus
as your HDDs.
>
> (the onboard Wi-Fi BTW is SDIO; so if you avoid using the
onboard Wi-Fi, I guess you might also
>  be able to make your µSD card faster...)
>
> ALSO: you'll really want to use an externally-powered USB
hub for USB devices
> that are not totally trivial, because the raspi's µUSB power
supply is already
> strained... (and if you're trying to power your raspi from
some random USB power supply,
> don't. Ideally you power it through the 5V pins on the

Re: Have suggestions for a "roll your own file server"?

[Bruce Labitt]

I'll take a look at that.  Thanks for the link.

On Wed, Mar 10, 2021 at 8:15 PM Marc Nozell (m...@nozell.com) <
noz...@gmail.com> wrote:

> Just to put a plug in for a colleague's work:
> https://perfectmediaserver.com/It covers everything from disk
> purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).
>
> He also hosts a podcast that folks here may find interesting:
> https://selfhosted.show/
>
> -marc
>
> On Wed, Mar 10, 2021 at 8:08 PM  wrote:
>
>> OK:
>>
>> s/RPi4/some-other-cheap-computer-with-USB-3.x>/g
>>
>> Unless you build multiple Ethernet or WiFi or LTE modem connections your
>> networking will still be the slowest thing.
>>
>> You do not need huge amounts of CPU power, or huge amounts of RAM.
>>
>> My basic point is that if you stick with simple RAID (like mirroring) but
>> also set up a unit that is remote from your own home you could protect your
>> own data from fire, flood and theft to a reasonable level and even protect
>> your friend's data by backing up their data to your device.
>>
>> Add snapshots as suggested by Tom Buskey,perhaps encryption of file
>> systems and data-streams and you can have a rather simple, server where you
>> learn a lot by planning it out and setting it up rather than buying an "off
>> the shelf" solution or simply using a "web backup".
>>
>> And good catch on the USB power supply.
>>
>> md
>> > On 03/10/2021 6:53 PM Joshua Judson Rosen 
>> wrote:
>> >
>> >
>> > I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there
>> are... problems, e.g.:
>> >
>> > Beware of USB on the raspi: there are some bugs in the silicon that
>> pretty severely
>> > cripple performance when multiple `bulk' devices are used at
>> simultaneously,
>> > sometimes to the point of making it unusable (e.g. if you want to use a
>> better Wi-Fi
>> > adapter/antenna than the one built onto the board, and connect an LTE
>> modem so that
>> > your raspi roam onto that if Wi-Fi becomes unavailable, throughput on
>> whichever of those
>> > interfaces you're actually using can become abysmal). IIRC the issue is
>> basically
>> > that the number of USB endpoints that can be assigned interrupts by the
>> raspi controller
>> > is _incredibly small_; and it's common for high-throughput devices to
>> have multiple endpoints per device--
>> > sometimes even one USB device will have more endpoints that the raspi
>> USB controller can handle.
>> >
>> > Also, `network fileserver with USB-attached hard drives' is kind of the
>> `peak unfitness'
>> > for the raspberry pi. Specifically if you've got it attached to
>> ethernet,
>> > the ethernet is attached through the same slow-ish USB bus as your HDDs.
>> >
>> > (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard
>> Wi-Fi, I guess you might also
>> >  be able to make your µSD card faster...)
>> >
>> > ALSO: you'll really want to use an externally-powered USB hub for USB
>> devices
>> > that are not totally trivial, because the raspi's µUSB power supply is
>> already
>> > strained... (and if you're trying to power your raspi from some random
>> USB power supply,
>> > don't. Ideally you power it through the 5V pins on the expansion
>> header...).
>> >
>> >
>> > Though there is a lot of neat stuff that can be done with a Raspberry
>> Pi,
>> > it's really easy to overestimate it.
>> >
>> > But on the other hand: YMMV, and there are scenarios where the issues
>> don't matter,
>> > and might not even be noticeable. e.g., if you're dumping periodic
>> backups to your
>> > raspi asynchronously instead of (say) NFS mounting it and trying to use
>> it interactively,
>> > you might not even notice the weird bottlenecks because you're never
>> looking at them.
>> > And if you have enough of them as spares running simultaneously, you
>> may not care
>> > that every once in a while your fileystems get corrupted or your USB
>> ports stop working
>> > or whatever.
>> >
>> >
>> > On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
>> > > I will suggest something and let people rip it apart:
>> > >
>> > > Get two RPis that have at least USB 2.0  Attach two large capacity
>> disks to each one in a RAID-1 configuration (also known as "mirroring") to
>> keep it simple.  If one disk fails the other will still keep working (but
>> you should replace it as soon as possible).
>> > >
>> > > Put all of your data on both systems.
>> > >
>> > > Take one of your systems to a friends or relatives house who you
>> trust that has relatively good WiFi.  Make sure the friend is relatively
>> close, but is not in the same flood plain or fire area you are.
>> > >
>> > > Do an rsync every night to keep them in sync.
>> > >
>> > > Help your friend/relative do the same thing, keeping a copy of their
>> data in your house.   If your disks are big enough you could share systems
>> and disks.
>> > >
>> > > Use encryption as you wish.
>> > >
>> > > Disk failure?   Replace the disk and the data will be replicated.
>> > > Fire, theft, earthquake?   Take the 

Re: Have suggestions for a "roll your own file server"?

[Bruce Labitt]

Actually, at the moment I am forced to run on a RPI4-4GB.  My laptop PS
died.  I'm aware of many of the downfalls of an RPI, I've had a few PI's
over the ages.  Mercifully, they are getting better.  One cannot run an SSD
AND and active USB3 hub both plugged directly into the 2 available USB3
ports.  The RPI4 will not boot.  The active hub's voltage backfeeds into
the Pi and the PI senses this, and prevents booting.  If however, the
active hub is buffered by a passive hub, it will work.  I discovered this
accidentally.

Anyhow, it's not too bad with two disks plugged into the active USB3 hub.
I had to rsync my laptop NVME to another NVME and it was sort of slow, but
I was transferring over 110GB.  Average transfer rate was over 90MB/sec for
all sorts of large and millions of small files.  Yeah not super fast, but
tolerable.  The file transfer was happening all the while I was using the
RPI4 for browsing with 14 active tabs.

I'm not using the SD card at the moment - that's unbearably slow.  I boot
from SSD.  (I lasted about a day using the RPI4 as a computer on an SD.  I
then ordered a $20 120GB SSD!)  Doing that, the RPI4 is tolerable,
especially with a slight overclock.  The RPI4 is a limited platform, but
it's not horrible, like it's predecessors were.  The earlier versions are
ok for print servers, sprinkler controllers and DNS filters (pihole).  I
think an RPI4 could make an ok host for a mirror array.  Don't know how to
do it yet, but it seems very approachable.

What I haven't figured out is how to have a remote offsite PI as well.
Just don't know how to secure it and be able to access it remotely.  At the
moment it's beyond my skill set.


On Wed, Mar 10, 2021 at 6:54 PM Joshua Judson Rosen 
wrote:

> I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there
> are... problems, e.g.:
>
> Beware of USB on the raspi: there are some bugs in the silicon that pretty
> severely
> cripple performance when multiple `bulk' devices are used at
> simultaneously,
> sometimes to the point of making it unusable (e.g. if you want to use a
> better Wi-Fi
> adapter/antenna than the one built onto the board, and connect an LTE
> modem so that
> your raspi roam onto that if Wi-Fi becomes unavailable, throughput on
> whichever of those
> interfaces you're actually using can become abysmal). IIRC the issue is
> basically
> that the number of USB endpoints that can be assigned interrupts by the
> raspi controller
> is _incredibly small_; and it's common for high-throughput devices to have
> multiple endpoints per device--
> sometimes even one USB device will have more endpoints that the raspi USB
> controller can handle.
>
> Also, `network fileserver with USB-attached hard drives' is kind of the
> `peak unfitness'
> for the raspberry pi. Specifically if you've got it attached to ethernet,
> the ethernet is attached through the same slow-ish USB bus as your HDDs.
>
> (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard Wi-Fi, I
> guess you might also
>  be able to make your µSD card faster...)
>
> ALSO: you'll really want to use an externally-powered USB hub for USB
> devices
> that are not totally trivial, because the raspi's µUSB power supply is
> already
> strained... (and if you're trying to power your raspi from some random USB
> power supply,
> don't. Ideally you power it through the 5V pins on the expansion
> header...).
>
>
> Though there is a lot of neat stuff that can be done with a Raspberry Pi,
> it's really easy to overestimate it.
>
> But on the other hand: YMMV, and there are scenarios where the issues
> don't matter,
> and might not even be noticeable. e.g., if you're dumping periodic backups
> to your
> raspi asynchronously instead of (say) NFS mounting it and trying to use it
> interactively,
> you might not even notice the weird bottlenecks because you're never
> looking at them.
> And if you have enough of them as spares running simultaneously, you may
> not care
> that every once in a while your fileystems get corrupted or your USB ports
> stop working
> or whatever.
>
>
> On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
> > I will suggest something and let people rip it apart:
> >
> > Get two RPis that have at least USB 2.0  Attach two large capacity disks
> to each one in a RAID-1 configuration (also known as "mirroring") to keep
> it simple.  If one disk fails the other will still keep working (but you
> should replace it as soon as possible).
> >
> > Put all of your data on both systems.
> >
> > Take one of your systems to a friends or relatives house who you trust
> that has relatively good WiFi.  Make sure the friend is relatively close,
> but is not in the same flood plain or fire area you are.
> >
> > Do an rsync every night to keep them in sync.
> >
> > Help your friend/relative do the same thing, keeping a copy of their
> data in your house.   If your disks are big enough you could share systems
> and disks.
> >
> > Use encryption as you wish.
> >
> > Disk failure?   

Re: Have suggestions for a "roll your own file server"?

[Marc Nozell (m...@nozell.com)]

Just to put a plug in for a colleague's work:
https://perfectmediaserver.com/It covers everything from disk
purchasing strategies, burn-in, filesystems (ZFS, SnapRAID, etc).

He also hosts a podcast that folks here may find interesting:
https://selfhosted.show/

-marc

On Wed, Mar 10, 2021 at 8:08 PM  wrote:

> OK:
>
> s/RPi4/some-other-cheap-computer-with-USB-3.x>/g
>
> Unless you build multiple Ethernet or WiFi or LTE modem connections your
> networking will still be the slowest thing.
>
> You do not need huge amounts of CPU power, or huge amounts of RAM.
>
> My basic point is that if you stick with simple RAID (like mirroring) but
> also set up a unit that is remote from your own home you could protect your
> own data from fire, flood and theft to a reasonable level and even protect
> your friend's data by backing up their data to your device.
>
> Add snapshots as suggested by Tom Buskey,perhaps encryption of file
> systems and data-streams and you can have a rather simple, server where you
> learn a lot by planning it out and setting it up rather than buying an "off
> the shelf" solution or simply using a "web backup".
>
> And good catch on the USB power supply.
>
> md
> > On 03/10/2021 6:53 PM Joshua Judson Rosen 
> wrote:
> >
> >
> > I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there
> are... problems, e.g.:
> >
> > Beware of USB on the raspi: there are some bugs in the silicon that
> pretty severely
> > cripple performance when multiple `bulk' devices are used at
> simultaneously,
> > sometimes to the point of making it unusable (e.g. if you want to use a
> better Wi-Fi
> > adapter/antenna than the one built onto the board, and connect an LTE
> modem so that
> > your raspi roam onto that if Wi-Fi becomes unavailable, throughput on
> whichever of those
> > interfaces you're actually using can become abysmal). IIRC the issue is
> basically
> > that the number of USB endpoints that can be assigned interrupts by the
> raspi controller
> > is _incredibly small_; and it's common for high-throughput devices to
> have multiple endpoints per device--
> > sometimes even one USB device will have more endpoints that the raspi
> USB controller can handle.
> >
> > Also, `network fileserver with USB-attached hard drives' is kind of the
> `peak unfitness'
> > for the raspberry pi. Specifically if you've got it attached to ethernet,
> > the ethernet is attached through the same slow-ish USB bus as your HDDs.
> >
> > (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard Wi-Fi,
> I guess you might also
> >  be able to make your µSD card faster...)
> >
> > ALSO: you'll really want to use an externally-powered USB hub for USB
> devices
> > that are not totally trivial, because the raspi's µUSB power supply is
> already
> > strained... (and if you're trying to power your raspi from some random
> USB power supply,
> > don't. Ideally you power it through the 5V pins on the expansion
> header...).
> >
> >
> > Though there is a lot of neat stuff that can be done with a Raspberry Pi,
> > it's really easy to overestimate it.
> >
> > But on the other hand: YMMV, and there are scenarios where the issues
> don't matter,
> > and might not even be noticeable. e.g., if you're dumping periodic
> backups to your
> > raspi asynchronously instead of (say) NFS mounting it and trying to use
> it interactively,
> > you might not even notice the weird bottlenecks because you're never
> looking at them.
> > And if you have enough of them as spares running simultaneously, you may
> not care
> > that every once in a while your fileystems get corrupted or your USB
> ports stop working
> > or whatever.
> >
> >
> > On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
> > > I will suggest something and let people rip it apart:
> > >
> > > Get two RPis that have at least USB 2.0  Attach two large capacity
> disks to each one in a RAID-1 configuration (also known as "mirroring") to
> keep it simple.  If one disk fails the other will still keep working (but
> you should replace it as soon as possible).
> > >
> > > Put all of your data on both systems.
> > >
> > > Take one of your systems to a friends or relatives house who you trust
> that has relatively good WiFi.  Make sure the friend is relatively close,
> but is not in the same flood plain or fire area you are.
> > >
> > > Do an rsync every night to keep them in sync.
> > >
> > > Help your friend/relative do the same thing, keeping a copy of their
> data in your house.   If your disks are big enough you could share systems
> and disks.
> > >
> > > Use encryption as you wish.
> > >
> > > Disk failure?   Replace the disk and the data will be replicated.
> > > Fire, theft, earthquake?   Take the replaced system over to your
> friends/relatives and copy the data at high speed, then take the copied
> system back to your house and start using it again.
> > >
> > > You would need three disks to fail at relatively the same time to lose
> your data.   Or an asteroid crashing 

Re: Have suggestions for a "roll your own file server"?

[jonhall80]

OK:

s/RPi4/some-other-cheap-computer-with-USB-3.x>/g

Unless you build multiple Ethernet or WiFi or LTE modem connections your 
networking will still be the slowest thing.

You do not need huge amounts of CPU power, or huge amounts of RAM.

My basic point is that if you stick with simple RAID (like mirroring) but also 
set up a unit that is remote from your own home you could protect your own data 
from fire, flood and theft to a reasonable level and even protect your friend's 
data by backing up their data to your device.

Add snapshots as suggested by Tom Buskey,perhaps encryption of file systems and 
data-streams and you can have a rather simple, server where you learn a lot by 
planning it out and setting it up rather than buying an "off the shelf" 
solution or simply using a "web backup".

And good catch on the USB power supply.

md
> On 03/10/2021 6:53 PM Joshua Judson Rosen  wrote:
> 
>  
> I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there are... 
> problems, e.g.:
> 
> Beware of USB on the raspi: there are some bugs in the silicon that pretty 
> severely
> cripple performance when multiple `bulk' devices are used at simultaneously,
> sometimes to the point of making it unusable (e.g. if you want to use a 
> better Wi-Fi
> adapter/antenna than the one built onto the board, and connect an LTE modem 
> so that
> your raspi roam onto that if Wi-Fi becomes unavailable, throughput on 
> whichever of those
> interfaces you're actually using can become abysmal). IIRC the issue is 
> basically
> that the number of USB endpoints that can be assigned interrupts by the raspi 
> controller
> is _incredibly small_; and it's common for high-throughput devices to have 
> multiple endpoints per device--
> sometimes even one USB device will have more endpoints that the raspi USB 
> controller can handle.
> 
> Also, `network fileserver with USB-attached hard drives' is kind of the `peak 
> unfitness'
> for the raspberry pi. Specifically if you've got it attached to ethernet,
> the ethernet is attached through the same slow-ish USB bus as your HDDs.
> 
> (the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard Wi-Fi, I 
> guess you might also
>  be able to make your µSD card faster...)
> 
> ALSO: you'll really want to use an externally-powered USB hub for USB devices
> that are not totally trivial, because the raspi's µUSB power supply is already
> strained... (and if you're trying to power your raspi from some random USB 
> power supply,
> don't. Ideally you power it through the 5V pins on the expansion header...).
> 
> 
> Though there is a lot of neat stuff that can be done with a Raspberry Pi,
> it's really easy to overestimate it.
> 
> But on the other hand: YMMV, and there are scenarios where the issues don't 
> matter,
> and might not even be noticeable. e.g., if you're dumping periodic backups to 
> your
> raspi asynchronously instead of (say) NFS mounting it and trying to use it 
> interactively,
> you might not even notice the weird bottlenecks because you're never looking 
> at them.
> And if you have enough of them as spares running simultaneously, you may not 
> care
> that every once in a while your fileystems get corrupted or your USB ports 
> stop working
> or whatever.
> 
> 
> On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
> > I will suggest something and let people rip it apart:
> > 
> > Get two RPis that have at least USB 2.0  Attach two large capacity disks to 
> > each one in a RAID-1 configuration (also known as "mirroring") to keep it 
> > simple.  If one disk fails the other will still keep working (but you 
> > should replace it as soon as possible).
> > 
> > Put all of your data on both systems.
> > 
> > Take one of your systems to a friends or relatives house who you trust that 
> > has relatively good WiFi.  Make sure the friend is relatively close, but is 
> > not in the same flood plain or fire area you are.
> > 
> > Do an rsync every night to keep them in sync.
> > 
> > Help your friend/relative do the same thing, keeping a copy of their data 
> > in your house.   If your disks are big enough you could share systems and 
> > disks.
> > 
> > Use encryption as you wish.
> > 
> > Disk failure?   Replace the disk and the data will be replicated.
> > Fire, theft, earthquake?   Take the replaced system over to your 
> > friends/relatives and copy the data at high speed, then take the copied 
> > system back to your house and start using it again.
> > 
> > You would need three disks to fail at relatively the same time to lose your 
> > data.   Or an asteroid crashing that wipes out all life on the planet.  
> > Unlikely.
> > 
> > Realize that nothing is forever.
> > 
> > md
> >> On 03/08/2021 7:33 PM Bruce Labitt  wrote:
> >>  
> >>  
> >> For the second time in 3 months I have had a computer failure.  Oddly, it 
> >> was a PS on the motherboard both times.  (Two different MB's.)  
> >> Fortunately the disks were ok.  I'm living on borrowed time.  Next time, I 
> 

Re: Have suggestions for a "roll your own file server"?

[Joshua Judson Rosen]

I'm not sure about the Raspberry Pi 4, but up thru the raspi 3+ there are... 
problems, e.g.:

Beware of USB on the raspi: there are some bugs in the silicon that pretty 
severely
cripple performance when multiple `bulk' devices are used at simultaneously,
sometimes to the point of making it unusable (e.g. if you want to use a better 
Wi-Fi
adapter/antenna than the one built onto the board, and connect an LTE modem so 
that
your raspi roam onto that if Wi-Fi becomes unavailable, throughput on whichever 
of those
interfaces you're actually using can become abysmal). IIRC the issue is 
basically
that the number of USB endpoints that can be assigned interrupts by the raspi 
controller
is _incredibly small_; and it's common for high-throughput devices to have 
multiple endpoints per device--
sometimes even one USB device will have more endpoints that the raspi USB 
controller can handle.

Also, `network fileserver with USB-attached hard drives' is kind of the `peak 
unfitness'
for the raspberry pi. Specifically if you've got it attached to ethernet,
the ethernet is attached through the same slow-ish USB bus as your HDDs.

(the onboard Wi-Fi BTW is SDIO; so if you avoid using the onboard Wi-Fi, I 
guess you might also
 be able to make your µSD card faster...)

ALSO: you'll really want to use an externally-powered USB hub for USB devices
that are not totally trivial, because the raspi's µUSB power supply is already
strained... (and if you're trying to power your raspi from some random USB 
power supply,
don't. Ideally you power it through the 5V pins on the expansion header...).


Though there is a lot of neat stuff that can be done with a Raspberry Pi,
it's really easy to overestimate it.

But on the other hand: YMMV, and there are scenarios where the issues don't 
matter,
and might not even be noticeable. e.g., if you're dumping periodic backups to 
your
raspi asynchronously instead of (say) NFS mounting it and trying to use it 
interactively,
you might not even notice the weird bottlenecks because you're never looking at 
them.
And if you have enough of them as spares running simultaneously, you may not 
care
that every once in a while your fileystems get corrupted or your USB ports stop 
working
or whatever.


On 3/8/21 9:56 PM, jonhal...@comcast.net wrote:
> I will suggest something and let people rip it apart:
> 
> Get two RPis that have at least USB 2.0  Attach two large capacity disks to 
> each one in a RAID-1 configuration (also known as "mirroring") to keep it 
> simple.  If one disk fails the other will still keep working (but you should 
> replace it as soon as possible).
> 
> Put all of your data on both systems.
> 
> Take one of your systems to a friends or relatives house who you trust that 
> has relatively good WiFi.  Make sure the friend is relatively close, but is 
> not in the same flood plain or fire area you are.
> 
> Do an rsync every night to keep them in sync.
> 
> Help your friend/relative do the same thing, keeping a copy of their data in 
> your house.   If your disks are big enough you could share systems and disks.
> 
> Use encryption as you wish.
> 
> Disk failure?   Replace the disk and the data will be replicated.
> Fire, theft, earthquake?   Take the replaced system over to your 
> friends/relatives and copy the data at high speed, then take the copied 
> system back to your house and start using it again.
> 
> You would need three disks to fail at relatively the same time to lose your 
> data.   Or an asteroid crashing that wipes out all life on the planet.  
> Unlikely.
> 
> Realize that nothing is forever.
> 
> md
>> On 03/08/2021 7:33 PM Bruce Labitt  wrote:
>>  
>>  
>> For the second time in 3 months I have had a computer failure.  Oddly, it 
>> was a PS on the motherboard both times.  (Two different MB's.)  Fortunately 
>> the disks were ok.  I'm living on borrowed time.  Next time, I may not be 
>> that lucky.  
>>  
>> Need a file server system with some sort of RAID redundancy.  I want to 
>> backup 2 main computers, plus photos.  Maybe this RPI4 too, since that's 
>> what I'm running on, due to the second failure.  If this SSD goes, I'm gonna 
>> be a sad puppy.  This is for home use, so we are not talking Exabytes.  I'm 
>> thinking about 2-4TB of RAID.  Unless of course, RAID is obsolete these 
>> days.  Honestly, I find some of the levels of RAID confusing.  I want 
>> something that will survive a disk
>> failure (or two) out of the array.  Have any ideas, or can you point me to 
>> some place that discusses this somewhat intelligently?
>>  
>> Are there reasonable systems that one can put together oneself these days?  
>> Can I repurpose an older PC for this purpose?  Or an RPI4?  What are the 
>> gotchas of going this way?
>>  
>> I want to be able to set up a daily rsync or equivalent so we will lose as 
>> little as possible.  At the moment, I'm not thinking about surviving fire or 
>> disaster.  Maybe I should, but I suspect the costs balloon considerably.  

Re: Have suggestions for a "roll your own file server"?

[Tom Buskey]

And make sure you get alerts when something fails.

There are a number of commercial NAS like Synology out there if you don't
want to build it yourself.

I'd also add some kind of offsite storage.  If you have decent internet
speed, cloud storage is a good choice.

Something with error correction is also good.

What I do:
I have the OS on its own disk.  I've done RAID in the past, but I'm ok with
rebuilding the OS.  A failed drive == forced upgrade.  For home, I'm ok
with this for heat/electricity costs.

For data, I've been using ZFS on Solaris -> OpenSolaris -> Ubuntu,  I think
15+ years.  I'm very happy with it.
I've used as low as 1GB, but more is better.  Dual core with 4GB is enough
for a home system IMO
If you've ever used a NetApp, it is similar.
It has snapshots that can persist forever.  My system takes one every hour,
day, week, month and keeps them for some multiple of that time.
You can divide the pool into "partitions" with changing size limits
(quota).
RAID is part of the FS.  mirrors, stripes and a raid5 like raidz.  Also
variants that can survive the failure of 2 drives ( raidz2 ~ raid6 and
triple mirrors)
Error detection.  If there is an error, the FS stops writing to prevent
more.  It's a bad idea to run ZFS on single drives.
If you have RAID, the FS has another copy to reference and can self heal
the error.
It has compression built in with negligible performance hit.
It has dedup.  Don't use it IMO.  Maybe if you have infinite RAM.

You can't expand the pool by adding disks.  So a 3 disk RAIDZ can't be
expanded by adding a 4th.
You can replace/rebuild disks with larger disks to increase the pool size.
It works well.

I create mirrors.  When I need more space, I add another mirror with newer
drives.
Fewer spinning drives means less electricity used if that's a big issue.

The family uses samba, NFS or the web server to get to data.  SFTP also
works.  They don't have to care about the disks underneath unless they fill
up the share.  Then it's a quick quota change and ask them to pare down how
many copies of that CD they really need.

In the past I used Crashplan for offsite.  They no longer offer the
unlimited systems for personal use, but I think a single system with
unlimited space is available.

Snapshots cover: Oops!  I deleted it by accident, can I get it back?  Well,
except for deleting a "partition" or pool.
Off site covers:  Oops! The house burned down, where are the family photos.



On Mon, Mar 8, 2021 at 10:00 PM  wrote:

> I forgot one thing:
>
> Set up a shell script to do a simple diagnostic on both systems to detect
> a failed or failing system.  Run two or three times a day.
>
> md
>
> On 03/08/2021 9:56 PM jonhal...@comcast.net wrote:
>
>
> I will suggest something and let people rip it apart:
>
> Get two RPis that have at least USB 2.0  Attach two large capacity disks
> to each one in a RAID-1 configuration (also known as "mirroring") to keep
> it simple.  If one disk fails the other will still keep working (but you
> should replace it as soon as possible).
>
> Put all of your data on both systems.
>
> Take one of your systems to a friends or relatives house who you trust
> that has relatively good WiFi.  Make sure the friend is relatively close,
> but is not in the same flood plain or fire area you are.
>
> Do an rsync every night to keep them in sync.
>
> Help your friend/relative do the same thing, keeping a copy of their data
> in your house.   If your disks are big enough you could share systems and
> disks.
>
> Use encryption as you wish.
>
> Disk failure?   Replace the disk and the data will be replicated.
> Fire, theft, earthquake?   Take the replaced system over to your
> friends/relatives and copy the data at high speed, then take the copied
> system back to your house and start using it again.
>
> You would need three disks to fail at relatively the same time to lose
> your data.   Or an asteroid crashing that wipes out all life on the
> planet.  Unlikely.
>
> Realize that nothing is forever.
>
> md
>
> On 03/08/2021 7:33 PM Bruce Labitt  wrote:
>
>
> For the second time in 3 months I have had a computer failure.  Oddly, it
> was a PS on the motherboard both times.  (Two different MB's.)  Fortunately
> the disks were ok.  I'm living on borrowed time.  Next time, I may not be
> that lucky.
>
> Need a file server system with some sort of RAID redundancy.  I want to
> backup 2 main computers, plus photos.  Maybe this RPI4 too, since that's
> what I'm running on, due to the second failure.  If this SSD goes, I'm
> gonna be a sad puppy.  This is for home use, so we are not talking
> Exabytes.  I'm thinking about 2-4TB of RAID.  Unless of course, RAID is
> obsolete these days.  Honestly, I find some of the levels of RAID
> confusing.  I want something that will survive a disk failure (or two) out
> of the array.  Have any ideas, or can you point me to some place that
> discusses this somewhat intelligently?
>
> Are there reasonable systems that one can put together 

Re: Have suggestions for a "roll your own file server"?

[jonhall80]

I forgot one thing:

Set up a shell script to do a simple diagnostic on both systems to detect a 
failed or failing system.  Run two or three times a day.

md

> On 03/08/2021 9:56 PM jonhal...@comcast.net wrote:
>  
>  
> I will suggest something and let people rip it apart:
> 
> Get two RPis that have at least USB 2.0  Attach two large capacity disks 
> to each one in a RAID-1 configuration (also known as "mirroring") to keep it 
> simple.  If one disk fails the other will still keep working (but you should 
> replace it as soon as possible).
> 
> Put all of your data on both systems.
> 
> Take one of your systems to a friends or relatives house who you trust 
> that has relatively good WiFi.  Make sure the friend is relatively close, but 
> is not in the same flood plain or fire area you are.
> 
> Do an rsync every night to keep them in sync.
> 
> Help your friend/relative do the same thing, keeping a copy of their data 
> in your house.   If your disks are big enough you could share systems and 
> disks.
> 
> Use encryption as you wish.
> 
> Disk failure?   Replace the disk and the data will be replicated.
> Fire, theft, earthquake?   Take the replaced system over to your 
> friends/relatives and copy the data at high speed, then take the copied 
> system back to your house and start using it again.
> 
> You would need three disks to fail at relatively the same time to lose 
> your data.   Or an asteroid crashing that wipes out all life on the planet.  
> Unlikely.
> 
> Realize that nothing is forever.
> 
> md
> 
> > > On 03/08/2021 7:33 PM Bruce Labitt  
> wrote:
> >  
> >  
> > For the second time in 3 months I have had a computer failure.  
> > Oddly, it was a PS on the motherboard both times.  (Two different MB's.)  
> > Fortunately the disks were ok.  I'm living on borrowed time.  Next time, I 
> > may not be that lucky.  
> >  
> > Need a file server system with some sort of RAID redundancy.  I 
> > want to backup 2 main computers, plus photos.  Maybe this RPI4 too, since 
> > that's what I'm running on, due to the second failure.  If this SSD goes, 
> > I'm gonna be a sad puppy.  This is for home use, so we are not talking 
> > Exabytes.  I'm thinking about 2-4TB of RAID.  Unless of course, RAID is 
> > obsolete these days.  Honestly, I find some of the levels of RAID 
> > confusing.  I want something that will survive a disk failure (or two) out 
> > of the array.  Have any ideas, or can you point me to some place that 
> > discusses this somewhat intelligently?
> >  
> > Are there reasonable systems that one can put together oneself 
> > these days?  Can I repurpose an older PC for this purpose?  Or an RPI4?  
> > What are the gotchas of going this way?
> >  
> > I want to be able to set up a daily rsync or equivalent so we will 
> > lose as little as possible.  At the moment, I'm not thinking about 
> > surviving fire or disaster.  Maybe I should, but I suspect the costs 
> > balloon considerably.  I do not want to backup to the cloud because, plain 
> > and simple, I don't trust it to be fully secure.
> >  
> > Thanks for any and all suggestions.  
> > ___
> > gnhlug-discuss mailing list
> > gnhlug-discuss@mail.gnhlug.org
> > http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> > 
> > > ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Have suggestions for a "roll your own file server"?

[jonhall80]

I will suggest something and let people rip it apart:

Get two RPis that have at least USB 2.0  Attach two large capacity disks to 
each one in a RAID-1 configuration (also known as "mirroring") to keep it 
simple.  If one disk fails the other will still keep working (but you should 
replace it as soon as possible).

Put all of your data on both systems.

Take one of your systems to a friends or relatives house who you trust that has 
relatively good WiFi.  Make sure the friend is relatively close, but is not in 
the same flood plain or fire area you are.

Do an rsync every night to keep them in sync.

Help your friend/relative do the same thing, keeping a copy of their data in 
your house.   If your disks are big enough you could share systems and disks.

Use encryption as you wish.

Disk failure?   Replace the disk and the data will be replicated.
Fire, theft, earthquake?   Take the replaced system over to your 
friends/relatives and copy the data at high speed, then take the copied system 
back to your house and start using it again.

You would need three disks to fail at relatively the same time to lose your 
data.   Or an asteroid crashing that wipes out all life on the planet.  
Unlikely.

Realize that nothing is forever.

md

> On 03/08/2021 7:33 PM Bruce Labitt  wrote:
>  
>  
> For the second time in 3 months I have had a computer failure.  Oddly, it 
> was a PS on the motherboard both times.  (Two different MB's.)  Fortunately 
> the disks were ok.  I'm living on borrowed time.  Next time, I may not be 
> that lucky.  
>  
> Need a file server system with some sort of RAID redundancy.  I want to 
> backup 2 main computers, plus photos.  Maybe this RPI4 too, since that's what 
> I'm running on, due to the second failure.  If this SSD goes, I'm gonna be a 
> sad puppy.  This is for home use, so we are not talking Exabytes.  I'm 
> thinking about 2-4TB of RAID.  Unless of course, RAID is obsolete these days. 
>  Honestly, I find some of the levels of RAID confusing.  I want something 
> that will survive a disk failure (or two) out of the array.  Have any ideas, 
> or can you point me to some place that discusses this somewhat intelligently?
>  
> Are there reasonable systems that one can put together oneself these 
> days?  Can I repurpose an older PC for this purpose?  Or an RPI4?  What are 
> the gotchas of going this way?
>  
> I want to be able to set up a daily rsync or equivalent so we will lose 
> as little as possible.  At the moment, I'm not thinking about surviving fire 
> or disaster.  Maybe I should, but I suspect the costs balloon considerably.  
> I do not want to backup to the cloud because, plain and simple, I don't trust 
> it to be fully secure.
>  
> Thanks for any and all suggestions.  
> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
> 
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Have suggestions for a "roll your own file server"?

[jsf]

I know this is not really an answer to the question but I've spun up a
small server on AWS with some storage that I snapshot every 6 hours.. i
installed 'owncloud' on the server and i have an owncloud client on my
laptop and my iphone.. really happy with it.. share the space with the
whole family.  I prepaid for the server on AWS greatly reducing the cost of
running it..

Happy to provide more info on request.

J.

On Mon, Mar 8, 2021 at 8:10 PM bruce.lab...@myfairpoint.net <
bruce.lab...@myfairpoint.net> wrote:

> Nuts, what I meant was NAS.  There's open media vault, are there others
> that "easy enough" for relative beginners?
>
> Get BlueMail for Android 
> On Mar 8, 2021, at 7:35 PM, Bruce Labitt  wrote:
>>
>> For the second time in 3 months I have had a computer failure.  Oddly, it
>> was a PS on the motherboard both times.  (Two different MB's.)  Fortunately
>> the disks were ok.  I'm living on borrowed time.  Next time, I may not be
>> that lucky.
>>
>> Need a file server system with some sort of RAID redundancy.  I want to
>> backup 2 main computers, plus photos.  Maybe this RPI4 too, since that's
>> what I'm running on, due to the second failure.  If this SSD goes, I'm
>> gonna be a sad puppy.  This is for home use, so we are not talking
>> Exabytes.  I'm thinking about 2-4TB of RAID.  Unless of course, RAID is
>> obsolete these days.  Honestly, I find some of the levels of RAID
>> confusing.  I want something that will survive a disk failure (or two) out
>> of the array.  Have any ideas, or can you point me to some place that
>> discusses this somewhat intelligently?
>>
>> Are there reasonable systems that one can put together oneself these
>> days?  Can I repurpose an older PC for this purpose?  Or an RPI4?  What are
>> the gotchas of going this way?
>>
>> I want to be able to set up a daily rsync or equivalent so we will lose
>> as little as possible.  At the moment, I'm not thinking about surviving
>> fire or disaster.  Maybe I should, but I suspect the costs balloon
>> considerably.  I do not want to backup to the cloud because, plain and
>> simple, I don't trust it to be fully secure.
>>
>> Thanks for any and all suggestions.
>>
>> --
>>
>> gnhlug-discuss mailing list
>> gnhlug-discuss@mail.gnhlug.org
>> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>>
>> ___
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>


-- 
new email:  jfree...@hey.com
https://about.me/joshuafreeman
https://joshuasfreeman.me

[image: View Joshua S. Freeman's profile on LinkedIn]

___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Re: Have suggestions for a "roll your own file server"?

[bruce.lab...@myfairpoint.net]

Nuts, what I meant was NAS.  There's open media vault, are there others that 
"easy enough" for relative beginners?

⁣Get BlueMail for Android ​

On Mar 8, 2021, 7:35 PM, at 7:35 PM, Bruce Labitt  wrote:
>For the second time in 3 months I have had a computer failure.  Oddly,
>it
>was a PS on the motherboard both times.  (Two different MB's.)
>Fortunately
>the disks were ok.  I'm living on borrowed time.  Next time, I may not
>be
>that lucky.
>
>Need a file server system with some sort of RAID redundancy.  I want to
>backup 2 main computers, plus photos.  Maybe this RPI4 too, since
>that's
>what I'm running on, due to the second failure.  If this SSD goes, I'm
>gonna be a sad puppy.  This is for home use, so we are not talking
>Exabytes.  I'm thinking about 2-4TB of RAID.  Unless of course, RAID is
>obsolete these days.  Honestly, I find some of the levels of RAID
>confusing.  I want something that will survive a disk failure (or two)
>out
>of the array.  Have any ideas, or can you point me to some place that
>discusses this somewhat intelligently?
>
>Are there reasonable systems that one can put together oneself these
>days?
>Can I repurpose an older PC for this purpose?  Or an RPI4?  What are
>the
>gotchas of going this way?
>
>I want to be able to set up a daily rsync or equivalent so we will lose
>as
>little as possible.  At the moment, I'm not thinking about surviving
>fire
>or disaster.  Maybe I should, but I suspect the costs balloon
>considerably.  I do not want to backup to the cloud because, plain and
>simple, I don't trust it to be fully secure.
>
>Thanks for any and all suggestions.
>
>
>
>
>___
>gnhlug-discuss mailing list
>gnhlug-discuss@mail.gnhlug.org
>http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Have suggestions for a "roll your own file server"?

[Bruce Labitt]

For the second time in 3 months I have had a computer failure.  Oddly, it
was a PS on the motherboard both times.  (Two different MB's.)  Fortunately
the disks were ok.  I'm living on borrowed time.  Next time, I may not be
that lucky.

Need a file server system with some sort of RAID redundancy.  I want to
backup 2 main computers, plus photos.  Maybe this RPI4 too, since that's
what I'm running on, due to the second failure.  If this SSD goes, I'm
gonna be a sad puppy.  This is for home use, so we are not talking
Exabytes.  I'm thinking about 2-4TB of RAID.  Unless of course, RAID is
obsolete these days.  Honestly, I find some of the levels of RAID
confusing.  I want something that will survive a disk failure (or two) out
of the array.  Have any ideas, or can you point me to some place that
discusses this somewhat intelligently?

Are there reasonable systems that one can put together oneself these days?
Can I repurpose an older PC for this purpose?  Or an RPI4?  What are the
gotchas of going this way?

I want to be able to set up a daily rsync or equivalent so we will lose as
little as possible.  At the moment, I'm not thinking about surviving fire
or disaster.  Maybe I should, but I suspect the costs balloon
considerably.  I do not want to backup to the cloud because, plain and
simple, I don't trust it to be fully secure.

Thanks for any and all suggestions.
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/