SohoLab is the homelab section of CONRAM.IT — a dedicated space for writing about what actually happens when you run real hardware at home emulating when a bunch of computers suddenly became a lesson in almost corporate infrastructure.

The lab is small-office/home-office scale: rack-mounted hardware, Proxmox as the hypervisor platform, a mix of VMs and containers, network gear that earns its keep, and storage with opinions. It runs continuously, breaks occasionally, and gets rebuilt when something better comes along or when the previous approach turns out to have been optimistic.

What gets written up here is what comes out of that — component choices that weren't obvious, configurations that took longer than they should have, hardware quirks that aren't well documented anywhere else, and code snippets that solved a specific problem and might solve yours too. Not a manual. More of a record of what we did and what we'd do differently.

The back catalogue migrated from the root site: firewall build, LSI/MegaRAID storage management, SFTP backup pipelines, and a few others. More to come as the lab evolves and the backlog gets written up.

General IT commentary, career writing, and the occasional gaming detour stays at conram.it. This is the infrastructure layer.

We are releasing Gjallarform — a lightweight contact form engine designed for static and low-maintenance websites like Publii. Many site owners forget that EU websites must provide a working, reliable way for visitors to get in touch — and that external form services often raise GDPR concerns.

Link to the Project page on this site.

Gjallarform keeps everything on your own server: no third-party processors, no tracking, no external scripts, no CMS, no API keys. Just PHP and sendmail.

Spam protection is layered: a honeypot field catches automated bots silently, a time trap rejects suspiciously fast submissions, and an arithmetic challenge handles the human operators who get past the first two. Each layer is independent — turn on what you need.

It has been running on conram.it and rikardmalmborg.se long enough to have survived a real-world spam attack. That is what prompted the math challenge feature.

Version 0.95 public beta. Four files, one folder, one config block. PHP 8.1+, nothing else required.

View on GitHub

Part 2 of a series tracing a home lab from its first NAS in 2013 to the infrastructure of today. This time: decommissioned enterprise hardware, the first real steps into virtualisation, a wooden rack in the garage, a proper cabinet, and the first deliberate home-built server.

Free Enterprise Hardware

In 2016 or thereabouts, two HPE ProLiant DL380 G7 servers were decommissioned at work. The kind of thing that happens in corporate IT: hardware reaches end of lifecycle, gets written off, and someone asks if anyone wants it before it disappears into recycling.

I wanted them.

Two identical 2U rack servers, fully populated SFF drive bays, redundant 750W power supplies, and the particular heft of enterprise hardware designed to survive a datacentre rather than impress on a desk. These were machines built for a purpose well above anything a home network strictly needed. That was, of course, part of the appeal.

The Wooden Rack

The problem with enterprise rack servers is that they need somewhere to live. Before the proper cabinet arrived, the answer was a wooden rack in the garage — a DIY affair that held the ProLiants and, later, the Opteron. No photos survive from this era, and the rack itself is long gone. It served its purpose: keep the hardware off the floor, provide some structure, and establish the garage as the physical home of the lab.

It was not pretty. It was not engineered. But it held the hardware without complaint for years, and sometimes that is all a rack needs to do.

First Steps with ESXi

VMware ESXi went on both ProLiants, using the free tier. At the time, that was a very useful entry point: a proper hypervisor, free to use, with enough limitations to remind you that VMware still had a business model, but not enough to stop a home lab from learning with it.

This was my first real encounter with virtualisation. Windows VMs, Linux VMs, temporary machines, experiments that were created, tested, broken, deleted and rebuilt. Nothing permanent. Nothing critical. The Asustor NAS continued handling the household file storage. The ProLiants were for learning.

That distinction matters. The ProLiants taught me virtualisation, but they did not become the storage answer. They made it easier to experiment with operating systems and services, but they also exposed the limits of solving every problem with whatever enterprise hardware happened to be available.

The Storage Problem

The DL380 G7 is a 2U server with SFF — small form factor — drive bays. That sounds flexible until the individual drives are considered. These were roughly 480 GB drives, the kind that made sense in a datacentre where density, redundancy and IOPS could matter more than raw capacity.

In a home lab where the data collection was already pushing into double-digit terabytes, the arithmetic simply did not work.

Even with every bay filled across both servers, and even with no sensible redundancy at all, the total capacity could not cover the storage needs. There were too many small drives and not enough accumulated space to build a useful storage layout from them. The Asustor, with its six 3.5-inch bays and consumer-grade drives, held more useful storage than either ProLiant.

I have since changed my view somewhat. Many small SFF drives can work well in the right configuration, especially for VM storage, mirrors, performance-oriented pools or tiered layouts. But at the time, with a growing dataset that needed volume above all else, the SFF form factor was simply the wrong fit.

The realisation was not dramatic. It was just arithmetic. Enterprise hardware is built for enterprise problems, and home storage is often not one of them.

The First Deliberate Server Build

The ProLiants had arrived opportunistically. The Asustor had solved the first storage problem. But the lab needed something more deliberate: a machine chosen less because it was available and more because it suited the role.

There was an earlier AMD build on a Tyan board — a C32-based Opteron machine that predated the Supermicro build. The details of that machine are lost to time and a lack of documentation. It existed, it ran, it eventually gave way to something better documented. The record begins properly with the Supermicro.

The Opteron server was based on a Supermicro H8DCL-6F, a dual-socket server board with IPMI, dual Intel gigabit networking and an onboard LSI 2008 SAS controller. The CPUs were two AMD Opteron 4386 processors, giving the machine 16 physical cores in total.

The Opteron was not elegant. It lived in a tower case rather than a proper rackmount chassis, and it simply sat on a shelf in the rack. Inside, the two Opterons were cooled by a pair of old ASUS tower coolers — more enthusiast improvisation than conventional server design.

This was the first machine that felt less like an appliance and more like infrastructure. The ProLiants remained the virtualisation playground. The Asustor became less central over time. The Opteron became the practical backbone: storage, file serving, Windows Server duties, RAID experiments and eventually the platform around which more serious FreeNAS questions started to form.

Going Vertical — The Compaq Cabinet

By May 2020, the wooden rack had served its time. The lab had grown beyond what a DIY frame in the garage could reasonably hold, and the opportunity arose to acquire a proper enterprise rack cabinet: a Compaq 9000, 42U, full-depth, manufactured in June 2001 according to its QA label.

A 42U cabinet from the pre-HP-merger Compaq era is a serious piece of furniture. Heavy, overbuilt, perforated mesh doors front and rear for airflow, and more rack space than a home lab could reasonably fill. It went in the garage, and the ProLiants were mounted properly on rails by September 2020. The Opteron, still in its tower case, sat on a shelf inside. The wooden rack disappeared without ceremony.

The cabinet changed the lab in ways that were not entirely practical. It imposed a physical structure that made the setup feel more deliberate. Servers had positions. Cable routes had paths. There was a front and a back, a top and a bottom, and the expectation that things would be installed rather than placed.

Life in the Garage

None of this was quiet. Each ProLiant drew roughly 200 watts and made the kind of noise enterprise fans are designed to make: functional, persistent and completely indifferent to domestic sensibilities. The Opteron added its own heat and airflow requirements. The garage absorbed this without complaint. Running the same equipment in a living space would have been a different conversation entirely.

This was also the period where the lab started developing roles. There was no longer just "the storage box" or "the servers". There was a NAS, a virtualisation environment, a storage server, a rack, a switch, power distribution, backups, and an increasingly long list of things that had to be remembered when something stopped behaving.

That sounds obvious in hindsight. At the time, it was the quiet transition from owning hardware to running infrastructure.

The First Storage Rabbit Hole

FreeNAS, now TrueNAS, started appearing around this period, although not yet as a clean, dedicated storage platform. At first it was another experiment among many: could ZFS be brought into a Windows- and virtualisation-heavy home lab without rebuilding everything from scratch?

The short answer was: almost.

The longer answer became its own story.

The Opteron made that question more interesting because it already had several ingredients storage people care about: a server board, ECC memory, an LSI controller, a hardware RAID history and enough disks to make the result matter. It also had exactly the wrong temptation: perhaps it would be possible to keep Windows Server, keep the RAID mindset, and still somehow gain the benefits of FreeNAS and ZFS.

That is where the difference between "it boots" and "it should be trusted" started to become relevant. Storage platforms are not ordinary VMs. Disks, controllers, SMART data, passthrough, scrubs, resilvers and filesystem assumptions all matter.

The Exit

By 2022 the ProLiants had served their purpose. The virtualisation experiments they enabled had laid groundwork that would eventually lead to Proxmox on more deliberate hardware. The storage mismatch had been solved by other machines. ESXi itself was still running, still stable, still doing what it did well, but the lab had outgrown what the DL380s could offer.

They were sold as working servers sometime in 2022 or 2023. Both were still fully functional, both with their original drive complements, both with the 750W PSUs that had run reliably for years. They left the way they arrived: capable enterprise machines looking for a workload that matched their strengths.

The Opteron stayed longer in the story. It had become part of the lab's operating history: the first deliberate server build, the first serious storage platform, and the machine that pushed me from simple file serving into the messy territory where controllers, filesystems, virtualisation and recovery planning overlap.

The Broadcom Footnote

A year or two after the ProLiants left, Broadcom completed its acquisition of VMware and proceeded to dismantle the free ESXi tier that had made home lab virtualisation accessible to an entire generation of IT professionals. The timing was fortunate. The lab had already moved on.

But the old free ESXi tier was not merely a freebie. It was a learning path. Many professionals learned virtualisation at home on ESXi and later carried that familiarity into work. Removing that path may have made sense on a spreadsheet, but it also closed one of the more useful bridges between curiosity, self-training and professional competence.

Next in the series: FreeNAS enters the lab properly, or at least almost properly. ZFS, Hyper-V, passthrough disks, SMART data, stalled SMB copies, bad drives, and the uncomfortable lesson that storage systems punish assumptions faster than ordinary servers do.

This is Part 1 of a series tracing a home lab from its first NAS purchase in 2013 to the rack servers, firewalls, and domain controllers of today. It started, as these things always do, with a modest problem.

The Problem Everyone Hits

In 2013 our household had between three and five desktops running at any given time. Kids at home, multiple machines, and exactly zero coordination around where files actually lived. Documents on one machine, photos on another, media scattered wherever it happened to land when someone downloaded it. The question was always the same: which computer or USB drive is that file on?

It's a problem every household with more than one machine eventually runs into, and most people solve it with a USB drive they carry between rooms. We did that for a while. It worked right up until it didn't — and the moment you realise you've been editing a file on the wrong copy is the moment you start thinking about a proper file share.

The solution was obvious enough: one device, always on, accessible from every machine in the house. A NAS.

Choosing the Box

This was 2013. No AI assistants to summarise product comparisons. No chatbot to ask "what's the best 6-bay NAS for a home with three desktops?" The research was done the old-fashioned way: hardware review sites, forum threads, specification comparisons, and a healthy dose of reading between the lines.

The market at the time was dominated by Synology and QNAP. Both had strong reputations. Both had price tags to match. The unit I landed on was an Asustor AS-606T — a six-bay NAS that sat a step below the big two in brand recognition but matched or exceeded them on specifications for the money. It was a decision made on paper, without anyone to ask for a second opinion. The kind of decision you either get right or learn from expensively.

Six 2 TB drives went in, configured in RAID 5. That gave roughly 10 TB of usable space — a number that felt generous in 2013. It wouldn't stay that way.

Detail	Specification
Model	Asustor AS-606T — 6-bay tower NAS
Storage	6 × 2 TB in RAID 5 (~10 TB usable)
CPU	Intel® Atom™ 2.13 GHz Dual-Core Processor
RAM	3 GB — sufficient for file serving, not much else
Date	2013 — still running in 2026

What Went On It

Everything. That was the point — one place for all of it. Documents, media, project files, household records, and the ever-growing photo collection. The NAS became the central landing zone for the household's data, and within weeks it was obvious that this was how it should always have been. No more guessing which machine held the current version. No more USB drives migrating between rooms. Files went on the NAS, and everyone pulled from there. Asustor's ADM operating system supports a range of add-on applications — media servers, download managers, Docker containers, the usual NAS ecosystem. I deliberately left all of that alone. Three gigabytes of RAM and a mobile-class CPU made the choice easy: this box had one job, and I strongly felt that anything beyond file serving would compromise it. Better to do one thing reliably than three things badly.

The Photo Problem

The NAS was also supposed to solve the photo situation. It didn't. If anything, it made the scope of the problem visible for the first time.

Photos arrived from multiple directions: phone cameras syncing to iCloud or Google Photos, cameras offloading to desktop machines, screenshots and downloads landing wherever they happened to land. Some photos existed in the cloud, some on the NAS, some on individual machines, and a concerning number existed in all three places simultaneously — or worse, in slightly different versions across all three. No canonical master. No single source of truth.

Several attempts were made to sort this out over the years. None were completed. The data kept growing, there was never a clean starting point, and getting every household member aligned on a consistent workflow proved harder than any technical problem. iCloud and Google Photos have their own opinions about how photos should be organised, and those opinions rarely align with a folder hierarchy on a NAS.

This remains an open issue in 2026, even somewhat graver. The tools under consideration have changed — Photoprism, Damselfly — but the fundamental challenge hasn't: deduplication across three decades of accumulated photos from multiple sources, with no clean baseline to start from. The NAS didn't create this problem. It just made it impossible to ignore.

Outgrowing It

Ten terabytes felt spacious in 2013. By 2016 it didn't. Data has a way of growing that consistently outpaces whatever you allocated, and a household that's actively using a file share generates storage demand faster than anyone estimates when setting it up.

The drives were upgraded twice over the NAS's lifetime — first to six 4 TB drives, also in RAID5, then to the current set of six 6 TB drives. The last time to a RAID6 configuration, each time a multi-day rebuild. The original 2 TB and 4TB drives are long gone, replaced without ceremony. The 6 TB set, giving roughly 24 TB usable, is what runs today.

But capacity wasn't the only constraint. The NAS had 3 GB of RAM and a CPU designed for low power consumption, not performance. It handled file serving perfectly well — that's what it was built for. But it couldn't also serve as a backup target for other systems without bogging down, and it certainly couldn't run virtual machines or containers. As the ambitions for the home network grew, the NAS increasingly felt like it was doing exactly one thing and had no room to do anything more.

What was needed was a proper server. Something with real processing power, enough RAM to run services alongside storage, and the headroom to grow into whatever came next. The NAS wouldn't be replaced — it would be demoted.

Keeping the Protocol current

By 2017, it was painfully obvious that SMB v1 was flawed — a real hazard to run on any storage device exposed to a network. After some consultations with Asustor and working through early adoption issues in ADM's support for later SMB versions, I enabled SMB 2/3 and disabled v1 permanently. 

The Demotion

When the first real server arrived — a custom-built AMD Opteron machine with a Supermicro dual-socket board, assembled from used parts — the NAS handed over its primary file-serving duties and moved to backup. The transition involved copying the entire data set from the Opteron to the Asustor with full verification.

That week-long copy has been repeated two or three more times since, each time as part of a hardware change or a drive upgrade cycle. It's never fast. It's never exciting. It's the kind of operational discipline that you either do properly or regret the one time you don't. The NAS accepted its demotion gracefully. It doesn't run apps. It doesn't host containers. It doesn't serve media. It sits on the network at 192.168.10.100, receives backup data on schedule, and does absolutely nothing else. That simplicity is precisely why it's still reliable in 2026.

Still Running... but

I am looking around now and then for a replacement. While the physical capabilities are enough, the hardware sufficient and capacity not yet wanting, the software is aging. Asustor have launched several upgrades to its ADM OS, but my NAS is incompatible and I do not intend to try anything else. It works. This is of course not a huge problem, since it only sits in a secluded place receiving files and is not exposed in any way

Next in the series: Free enterprise hardware arrives from work, VMware ESXi enters the picture, and the NAS gets its first companion — a pair of HPE ProLiant DL380s that came with a storage arithmetic problem nobody saw coming.

There are questions about this floating around the internet like digital tumbleweed, and I

The LSI/Avago MegaRAID Storage Manager (MSM) is not exactly new technology, but if you are still running one of these RAID cards — rebranded or otherwise — you probably still need the management interface.

So here it is, documented...

Disclaimer: Provided as-is, no warranties. There are other Java configurations, other approaches, and entirely other solutions. This guide assumes you are not a Java developer with knowledge about version management. If you are — feel free to improvise, but the path described here is not wrong simply because a different path also exists.

What You Need

Download the required package here: [DOWNLOAD LINK] 104MB, approximately.

The package contains the MSM installer, the 32-bit Oracle JRE Setup, and the javax.activation.jar file that MSM quietly requires but does not always make obvious.

Installation

Step 1 — Install Oracle Java i586 (32-bit)

Yes, 32-bit. On an x64 OS. The x64 version of Java did not work; the 32-bit version does. Do not overthink it.

During installation, choose a destination folder with no spaces in the path.
This matters later.

A clean example:C:\OracleJRE32

The installer included in the package is the  version tested with this guide.

You can use a newer version from the Oracle site if preferred, but your mileage may vary.

Step 2 — Set the JRE_HOME Environment Variable

Once Java is installed, create a system environment variable pointing to the installation folder:

• Variable name: JRE_HOME
• Variable value: C:\OracleJRE32 (or wherever you installed it)

Environment variables live in System Properties > Advanced > Environment Variables.

This applies to most Windows versions. Microsoft's own documentation covers it if you need a walkthrough: Environment Variables — Microsoft Learn.

Step 3 — Reboot

Reboot the machine. Environment variables need a fresh session to take effect.

Step 4 — Verify Java

Open a Command Prompt and run:

java -version

Note the single dash — it is -version, not --version. You should see the installed JRE details. If you get an error, the environment variable is not set correctly or the reboot did not happen.

Step 5 — Copy javax.activation.jar into the Java /bin/ Folder

From the downloaded package, copy the file javax.activation.jar into the /bin/ subfolder of your Java installation:

C:\OracleJRE32\bin\

This file is listed as a separate download in the official ReadMe.txt and it is not optional — without it, MSM will fail to locate the server. It is included in the package to save you the hunt.

Step 6 — Install MSM

Run the MSM installer. A few prompts worth noting:

LDAP prompt: Select No if you do not have a running LDAP server. Most people do not.

Key size prompt: Both 2048 and 1024 worked in testing. Either is fine.

Remaining prompts: Default selections throughout. Nothing exotic required.

No additional reboot is needed after the MSM installation.

Done

MSM should now be installed and able to communicate with your RAID controller. If it cannot find the server, the most likely culprit is the missing javax.activation.jar — confirm it is in the right place before anything else.

As noted at the top, this has been tested on hardware not officially listed in the MSM supported device list. If your card is LSI-based or a rebranded variant thereof, there is a reasonable chance it works regardless of what the documentation claims.

If you run personal or non-profit websites on shared hosting, you probably already know that Installatron handles backups reasonably well — right up until your site grows large enough that keeping backups on the same host starts eating into your allocated space.

At which point you need somewhere else to put them. This is that somewhere else.

FTP is not the answer. FTP/S is marginally better but still not advisable. WebDAV exists if you enjoy configuring things that were not designed to be easy. The cleaner option is SFTP — encrypted, SSH-based, and straightforward to set up on a Windows machine with Bitvise SSH Server. SFTP is an SSH protocol and is considered secure when properly maintained. FTP is not. That is not a matter of opinion.

This guide covers setting up Bitvise as an SFTP target on a Windows machine and pointing Installatron at it for automated offsite backups.

What You Need

• A Windows machine — physical or virtual, does not matter. A repurposed server works fine.
• Bitvise SSH Server — free for personal use with reasonable limitations.

• 

   See the personal edition FAQ. Commercial licensing is available at $95/year for basic use.
•  
• Installatron running on your webhost — standard on many shared hosting control panels.
• Access to your router for port forwarding.
• A non-default port number. Port 22 is SFTP's default and a magnet for scanners. Pick something else — anything unused on your network. This guide uses 33391 as an example.

Network Setup — Port Forwarding

Before anything else, set up port forwarding on your router to direct your chosen port to the Windows machine running Bitvise. The specifics vary by router — portforward.com has guides for most brands.

Once configured, verify the port is actually open before proceeding. There is no point configuring Bitvise against a closed network path.

Dynamic IP — Worth Addressing Early

If your home internet connection uses a dynamic IP address (most residential connections do), you will need a DNS forwarding service to keep the address resolvable. Several providers offer this free for a single host. Portforward.com covers this as well. Sort it before you go further — discovering it mid-setup is avoidable frustration.

Setting Up Bitvise

Install Bitvise from bitvise.com and configure the following:

Port

Set Bitvise to listen on your forwarded port (33391 in this example). Avoid well-known ports — the full list is on Wikipedia if you need to check for conflicts. Ref: Bitvise connection guide.

Virtual Account

Create a virtual account — not a Windows account. The distinction matters for security. A virtual account is isolated and cannot be used to authenticate against Windows itself. Use a complex, lengthy username and password combination. This account will be accessible from the open internet; treat it accordingly. Something like mysftpaccounttobitvise with a password along the lines of 1FAVbJhZJvDoD2xS53gn97Ied gives the right idea. Ref: Bitvise SFTP configuration guide.

Backup Folder

Create a dedicated folder for backups and point the virtual account's root there. Keep it on a separate drive from the system drive — easier to monitor, easier to manage, and keeps backup data away from anything critical if something goes wrong.

Security

Read the Bitvise securing guide before going live. At minimum, restrict access to the IP address ranges of your webhost. Check the Bitvise activity log regularly — it is informative and will tell you early if something unexpected is attempting to connect.

Windows Firewall

Add an inbound rule in Windows Firewall allowing your chosen port. Start permissive — any protocol, any IP — and tighten once you have confirmed the connection works. Name the rule clearly; a rule called "33391 – Bitvise SFTP" is significantly easier to find six months later than one called "New Inbound Rule 4".

Make notes when you change firewall settings. It is easy to tick a box that seems like a security improvement and then forget about it entirely until connectivity breaks.

Windows Ransomware Protection (Controlled Folder Access)

If Windows Defender's Controlled Folder Access is enabled, it will block Bitvise from writing to the file system. You will need to explicitly allow the Bitvise service as a permitted application. This is another reason to use a dedicated backup folder on a dedicated drive — it makes the exception scope clean and obvious. Ref: Microsoft — Controlled Folder Access.

Configuring Installatron

In the Installatron backup interface, you will need five things. Be precise — spaces and

• Address — hostname or IP of your Bitvise machine
• Port — your forwarded port (33391)
• Username — your Bitvise virtual account username
• Password — the corresponding password
• Path — the backup folder path; forward and backward slashes are both accepted

Save each step in Installatron before moving to the next. It does not always retain unsaved changes when you navigate away. Run a manual backup first and confirm files actually appear at the destination before trusting the scheduled automation.

Backup files are stored as .gz archives — Linux compression, but readable and extractable on Windows with WinRAR or 7-Zip.

FAQ

Will this use up my host's bandwidth allowance?

Yes. Backup transfers count against your hosting bandwidth. Several hundred GB in a week is not implausible for larger sites. Check your hosting agreement before enabling scheduled backups.

Connection works but no files are appearing at the backup location.

Check Windows Firewall first. If Controlled Folder Access (Ransomware Protection) is enabled, it may be blocking the Bitvise service from writing. Also verify the virtual account has write access to the target folder root.

Multiple Installatron instances are all writing to the same folder despite different paths being set.

On some hosting control panels (DirectAdmin in particular), the active domain context matters when configuring Installatron backup settings. Make sure the correct domain is selected in the control panel before touching the backup configuration for that site — even if all sites appear in a single list.

Installatron reset the backup destination back to the webhost by itself.

Usually indicates the backup encountered an error, or the connection was never properly tested after setup. Check whether any files were created at the SFTP destination, and check adjacent folders. Also verify you are not accumulating unexpected backups on the webhost and consuming space you had not planned for. Starting fresh with that site's backup config is often the quickest resolution.

How do I restore from these backups?

If Installatron can locate and recognise the backup package directly from the SFTP path, restoration is straightforward. If not, upload the archive to a folder on the host and unpack it there, then point Installatron at the existing backup in its default local folder. Worst case — manual database restore and file upload. If you have any experience managing web applications, you already know how that works.

The author of this text is not affiliated with Bitvise, Installatron, or any other product mentioned.