Re: [PLUG] Is it possible to move data from a SAS drive to the newly installed SSD?

[H Mottaleb via plug <plug@lists.phillylinux.org>]

I have couple of desktops I can setup for this purpose. I will have to get the ssds though. Any suggestions on standard ssd or NVMe?

Once I have the system setup, should I install Ubuntu form scratch and reconfigure everything according to the guide or would it be possible for me to copy it all over?

Would you be able to walk me trough the steps to create the partitions, pvmoves for those partitions and /boot and the

bootloader that need special handling?

Sent from Yahoo Mail for iPad

On Monday, January 18, 2021, 2:32 PM, Rich Freeman via plug <plug@lists.phillylinux.org> wrote:

On Mon, Jan 18, 2021 at 2:16 PM Keith via plug
<plug@lists.phillylinux.org> wrote:
>
> My question is, is there some reason why the generic process for moving file systems on a node that is doing crypto mining would not work?  The only issue is see if the filesystem id is use in the proof of work mechanisms.  That is not impossible to address but it would add some complexity to the process.
>

Nope, that would work fine.  The only issue is that they're new to
linux and doing an email walkthrough for that could be tricky.  Also,
there is more than one mountpoint at this point, which is just a minor
detail but needs to be handled.  Also, much of it is on LVM so I'd
just do pvmoves for those partitions.  It is really just /boot and the
bootloader that need special handling.

I'd step back and look at the problem.  An eth node has really two sets of data:

1.  The blockchain, which is huge, constantly changing, and completely
available on the internet to download at any time,
2.  Any local wallets.  These are tiny, rarely change, and exist
nowhere else - if you lose these you lose any money in the associated
accounts.

I'd take this into account in the design, because constantly backing
up the blockchain seems like a lot of work for little reward.
Besides, geth is basically already setup to replicate it all
automatically anyway.

I'd just set up two simple nodes on commodity hardware (SSD-based,
with room for 100GB/yr of blockchain growth on LVM so it is easy to
expand/migrate).  This means that #1 is automatically covered with
100% redundancy at the host level.

Then I'd set up a backup solution for #2 appropriate to the value and
frequency of updates of the wallets.  If you rarely if ever create new
accounts then a manual backup of the wallet when it changes and before
putting money into new accounts might be the simplest solution.  If
you're frequently creating new accounts then you'll want automated
backups, and your recovery point objective is critical because you
lose any money deposited into an account between the time of its
creation and the next backup (but after it is backed up once any
future deposits are fine).

--
Rich
___________________________________________________________________________
Philadelphia Linux Users Group        --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --  http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug