I’m looking for a little advice here;
I have an installation of Nextcloud on a Linux server at home and it’s working perfectly.
What I’m wondering though, is if I should change the location of the data files. When I initially installed Nextcloud, I placed the data in a directory called /nextcloud off the root directory and I’m having second thoughts about it. The only trouble is, I’m not sure if I should change to another directory or leave it like it is. I’m asking from a security perspective.
I don’t have much data in Nextcloud at the moment, so now’s the time to make this decision before I’m all-in.
I’d appreciate comments and opinions…
With up to date and well configured webserver it does not matter from security perspective. However to allow some bad webserver configs (that do not deny direct access to nextcloud/data) it is safest to have it outside the web root.
External drive has the most benefit for SBCs, where the OS is placed on an SDcard or eMMC, which are usually much slower than external HDDs or of course SSDs and are vulnerable to causing data corruption when being used too heavy/long. SDcards are really not made for 24/7 access and will die relatively fast.
Thanks. It’s outside the web root now. I’m inclined to just leave it like it is. There’s no problem with my daily backups accessing the location. I couldn’t think of a security problem the way I’m doing it, but I’m not the world’s expert in security matters. It’s good to put the question out there.
You will want to move you data folder somewhere it isn’t beneath the webroot, such as /srv/nextcloud/data.
Thanks Karl,
Right now, the directory I’m using is a first tier directory from the root, called /nextcloud-data. Can you think of a reason why I should not do it that way? I know that it’s not generally done this way in Linux, but I don’t know why, which is why I’m asking.
It’s not beneath the webroot, but it’s not where someone with more experience would necessarily put it either.
hello,
jumping in. If any data writing directory gets full on a first tier directory, system simply crash.
RECOMMENDED PARTITIONING SCHEME ( not considering files system like btrf, ext, xfs …, raid, lvm )
64 bits systems, as 32 bits system are now irrelevant for production servers.
Usual recommended partition scheme 64 systems using one HDD/SSD :
-
A /boot partition
The partition mounted on /boot/ contains the operating system kernel (which allows your system to boot), along with files used during the bootstrap process. For most users, a 250 MB boot partition is sufficient.
-
A / root partition
A root partition — this is where " / " (the root directory) is located. Usually all files (except those stored in /boot ) are on the root partition. but /home and /var /mnt can be set on different partitions, even differents HDD/SSD
-
A home partition
A home partition (at least 100 MB), used to store user-data separately from system data, i usually create a dedicated partition within a volume group for the /home directory. This will enable you to upgrade or reinstall your distro without erasing user data files.
-
A /boot/efi partition (EFI System Partition) - only on systems with UEFI firmware
-
A swap partition (at least 256 MB) — Swap partitions support virtual memory: data is written to a swap partition when there is not enough RAM to store the data your system is processing.
In years past, the recommended amount of swap space increased linearly with the amount of RAM in the system. Modern systems often include hundreds of gigabytes of RAM, however. As a consequence, recommended swap space is considered a function of system memory workload, not system memory.
- Raid best practice.
Best practice for raid ( soft or hardware based ) is to use /mnt
Advice on Partitions
Optimal partition setup depends on the usage for the Linux system in question. The following tips may help you decide how to allocate your disk space.
-
Consider encrypting any partitions that might contain sensitive data. Encryption prevents unauthorized people from accessing the data on the partitions, even if they have access to the physical storage device. In most cases, you should at least encrypt the /home partition.
-
Each kernel installed on your system requires approximately 30 MB on the /boot partition. Unless you plan to install a great many kernels, the default partition size of 250 MB for /boot should suffice.
The /var directory holds content for a number of applications, including the Apache web server. It also is used to store downloaded update packages on a temporary basis. Ensure that the partition containing the /var directory has enough space to download pending updates and hold your other content.
In case of multi-disks: http://www.tldp.org/HOWTO/Multi-Disk-HOWTO.html
The point of moving it outside the web root is so the the data folder would theoretically not be served up as regular files in the event of a web server malfunction or breach. Anywhere else should be fine. I suggest /srv because it would be FHS compliant, but that’s entirely up to you. I don’t see any reason it wouldn’t work where you have it as long as your permissions are right.
This gives me a lot to think about. Thanks. The other side of the coin is that I am using LVM drives mounted in the /home directory to contain my personal data. At the moment I have two 3TB drives that make up one logical volume. I’m about to increase that to two 4TB drives (the current drives are beyond what I call their end of life dates). I could make either two logical volumes, mounted at /home and /srv, or one logical volume mounted at /home with my personal data and the cloud data located downstream from there. It makes no difference to my backup script.
So, what I have to think about is:
Put everything in the /home directory, which is easier to do when managing the LVM drives.
Or separate the nextcloud data into the /srv directory, which appears to be more consistent with industry recommendations. This is a bit more complicated, but not really when I think about it.
Whatever the end result is, I know that now’s the time to do it. I just made this install of Nextcloud and I’m not storing any data I don’t have backed up elsewhere. The current installation of Nextcloud was only intended as a “test” installation. I figured that at some point I would want to do a new install, or at least do a significant modification once I figured all this out.
Thanks again. This information has helped a lot.
I would not put Nextcloud under /home. It sounds like you’re using the “manual” installation method. Is that right?
In that case, I would leave the web root with Nextcloud files in the default location, and then I would put the data folder under /srv/nextcloud/data. Regardless of where you put it, the data folder should not be under the web root.
Since you’re using LVM, you don’t have to preallocate all of the space. I also just want to mention… you are using RAID-1 on those two drives, aren’t you? If you just throw them both into an LVM volume group, then you have double the normal risk of a drive failure because a failure of either drive will knock out the volume.
H.
Using an raid6 array (mdadm+lvm2) for NC-data and savedshare, mounted /mnt/raid6/nc-data
Using a dedicated ssd ( small one 128G ) for /var/www/html/nexcld for the obvious ( avoiding the files check rnd due to openssl in webroot )
and a 250Go ssd for the system itself ( with a daily snapshot saved on a raid6share )
Interesting, because I’ve already moved the data to /srv/nextcloud. The nextcloud php files, of course, remain under /var/www/nextcloud, where Apache can serve them up.
I’m not using a RAID-1. Instead, I’m using a striped array. My reasoning is that I’m trying to maximize the storage. I actually need 6TB for the data because of all the photos and videos we have. Instead of a RAID array, I’m doing daily backups of all the data, and I rotate that (the backups) among two sets of drives so that at least one backup is not physically present at the machine, in case of a lightning strike, hurricane, or whatever. And, to reduce the chance of a single drive failing and ruining the whole thing, I retire my drives when their manufacturer’s warranty expires. There are of course no guarantees in life, but I’m reasonably confident in the system I’m using now.
We’ve never had to recover data because of a hardware failure (yet), but we have had to go in and recover a file or two every now and then because of a horrible Photoshop mishap. It happens.
Thanks for your comments. I seriously appreciate them.
I’ve always maintained that I’m not smart enough to set up a RAID array. The truth is, I’m just too cheap. On my server, I have spinning drives, leaving the SSD drives for the desktop, where I do my video editing.
I didn’t set up any kind of RAID array when I originally set up the server because I didn’t understand them enough to trust my data with them, or, more accurately, I didn’t trust me to properly administer a RAID array with my data. Instead, for some reason, I became comfortable with LVM and using striped drives, partly for the speed, but mostly because it penciled out to be economical.
I do make regular backups though, and keep a full backup offline and away from the server.
RAID is actually pretty simple, and a striped array is essentially RAID-0, although LVM may not call it this. That’s up to you if you’re comfortable with potentially having to restore the entire system from backup one day. Of course on a production system you would never do it like this.
I just find it interesting that you don’t want to use RAID because you’re not sure about it, yet your chosen alternative doubles your risk of system failure whereas RAID mirroring would reduce it by half. I understand your reasoning behind it, and that’s entirely up to you, but I would never set a system up like that even at my house. I would encourage you for the future to experiment with RAID-1 and RAID-5 and get comfortable with it.
Your points are valid. It turns out that when I finish figuring this NextCloud out, I’ve got planned a re-evaluation of what I’m doing with the main data and its associated backups.
I’m running out of space, so I need to decide how much (if any) I want to expand compared to how much I want to archive and make available offline, and how much I just simply don’t need.
While I’m working all that out, I should probably look (again) at RAID-1. I don’t need RAID for the backups necessarily, but the main data certainly could benefit.
Well RAID is not supposed to be a substitute for your backups. You definitely still need to do your backups.
What RAID does for you is when you do eventually blow a hard drive, your server stays online, even while you replace it if your server has hot swap drives. So you don’t have the downtime and don’t have to restore your entire system from backup with each drive failure. It can also give you a read speed increase in some cases.