I’m looking to make the switch from FreeNAS to Rockstor, but don’t know whether to get v3.9.1 or v4.0.7. Normally, I’d just go with the stable release since I don’t want to have to tinker around with my NAS a bunch (already tinker around with Arch on my desktop plenty enough, lol), but I don’t know how painful the move from CentOS to OpenSUSE will be.
So my questions are: How much manual intervention has the beta required from the end users so far? If the general consensus is that end users of the beta haven’t had to do much, then switching to it until the stable release is in OpenSUSE seems like it’d be painless.
And what do we expect the transition to be from CentOS to OpenSUSE for existing users? Would it be significantly more involved than doing something like switching from the beta to a stable OpenSUSE release?
My first question would be why are you looking to move from FreeNAS to Rockstor? Im geniunely curious even as a fan of Rockstor.
I initially used v3 about a year ago, then around September I think it was I built the v4 installers for x86 and ARM mainly out of interest/curiousity, but then went on to do some testing and provided feedback to the developers here to help their journey.
I’ve been using V4 since around October last year without problem. The move from v3 to v4 is a fresh install as its a different base Linux distro, and once that is done it is a relatively easy task to migrate the existing data pools across.
Currently using the 4.0.7 version which has been rock stable for me (see what I did there ) and my recommendation would be to go for v4 rather than a stepping stone from V3 to v4.
Currently there is no official release for v4, but it is easily built in a VM from the excellent resources available here, which is what I did last year.
Yes, some users have encountered issues which is a natural part of things and a search around the forum will bring these up. However the developers here are very proactive and supportive of the user community. Also, it is a very friendly community, which to me is a very important factor.
One thing to bear in mind is that you will not be able to easily import your existing ZFS pools in to Rockstor, without some more fancy CLI action. However, assuming you have a backup this is a moot point. If you intend to build a brand new device with new disks, then it will be trivial to transfer the data across. Although obviously it could be a lengthy process depending on how much data you have and network speed.
My reason to switch from FreeNAS to Rockstor is a bit petty, lol. Basically, I converted an old computer into a FreeNAS machine about 1.5 years ago knowing almost nothing about NAS’s, and was using Arch with ext4 on my desktop at the time. I set up some scripts to rsync my important stuff from my home directory to the NAS, and that worked well. A couple months later, I learned about btrfs and switched to using Arch with btrfs on my desktop. After several months of using the rsync scripts on btrfs, I looked more into btrfs send/receive and thought that would be a nicer solution since it’d be faster and wouldn’t have the issue of the me being able to change files mid-sync. But FreeNAS is zfs, so I decided to switch my desktop to zfs instead, and use zfs send/receive. After I eventually got Arch with zfs on root installed, everything was working well. Except I really just can not stand having to update the Linux kernel separately from the rest of the stuff, waiting days until the zfs stuff gets put out there. It just really bugs me for some reason. I also feel more comfortable with btrfs (probably because I spent more time with it), and feel 100% sure I can salvage a bricked btrfs setup without help while I would probably have to Google a couple things with zfs. So, I figured I’d switch my NAS over to an OS that uses btrfs and switch my desktop back over to btrfs, as well.
So basically, I wasn’t satisfied with a perfectly functioning rsync backup solution, decided to switch to zfs for send/receive functionality, but wasn’t satisfied with the problems that come from zfs not being officially supported by Linux.
And I think I’ve got my bases covered for making the switch to Rockstor. I’ve moved any data that’s being stored solely on the NAS to my desktop (the important stuff, at least - I’m going to be purging a bunch of junk thanks to this move), so I’ll just install Rockstor on the NAS, wipe the two data drives that will be a RAID 1 mirror setup, move the stuff back onto the NAS, do an rsync backup of my desktop’s home directory to my NAS, do a fresh install of Arch with btrfs on my desktop, then rsync my home directory back to my desktop.
I’m a regular user of rsync myself actually, every night to my backup, and every week to a second backup. And then another backup for just my photos which are irreplaceable.
Yes, I am Mr Backup
I use raid1 on my Rockstor v4, and its been faultless so far. The beauty of btrfs compared to ZFS is you can add whatever drive you want at a later date and have a 3 drive raid1. I believe ZFS needs another matched vdev, or a rebuild from scratch There’s a useful online calculator for btrfs here which I have used a fair bit.
Note that Rockstor raid1 only has 2 copies of the data, the online calculator has options for more copies though which don’t apply here.
I installed Rockstor 4.something in early April and am currently on 4.0.4. There have been no issues with it. The machine is consists of about 6 old drives in a RAID1 array, 8GB memory, and an old AMD dual core processor. I’m running an Emby rockon and occasionally fire up the MariaDB rockon to play with it. It’s serving files via Samba for a variety of Windows machines and an iPad.
But to your question: the system has been rock solid and I expect you’ll be satisfied to that extent. There’s really been no intervention required since I got it up & running, other than when I added a drive or messed with the Rockons.
(I did discover, on another machine, that it runs very very very slowly using an old USB2 thumb drive to boot and an old USB2-connected hard drive for data. Too slow to even serve up Samba shares or act as a backup target.)