|
My router got 2 USB3 ports and an SMB server so setting up a file server wasn't an expensive ordeal.
I am pretty sure something more dedicated would yield more performance, but that doesn't matter for my use case.
That use case being first and foremost backups. Regular, background backup jobs. My second use case is using this heap of backup as a UPnP server (which the router also provides) so my media collection is readily available while the main PC is not running.
But backups alone are IMHO worth it.
|
|
|
|
|
|
Several, all Linux based.
Nothing succeeds like a budgie without teeth.
|
|
|
|
|
I had a cheap NAS to store family files, especially photos and videos. But, in the process of getting everybody their own laptops, I neglected to store copies for a while and regularly back it up, the NAS crashed, and we lost about 4 years of photos. So now, I simply keep such things in a backup USB drive and chips. No more NAS for me.
|
|
|
|
|
I have an old headless system with front hot-swappable drive bays, running Windows 7 and a bunch of file shares. I keep referring to it as my home NAS--which is undoubtedly a misnomer, but that's exactly how it's used.
Whether it's "worth it" depends on how you use it. I mostly use it to host files that would otherwise be spread across the Downloads and Documents folders of a bunch of individual machines. I try to avoid that and dump everything onto the system with the file share.
It's also my installer archive. New machine needs an app or an ISO of a CD/DVD? With proper organization, that I've worked out over decades, I can find just about anything within 10 seconds just browsing the file system. Windows Search is slower than that.
|
|
|
|
|
|
I have my own server in my home-office.
Its a great assist in testing development for client-server or web applications...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
I assume you've gone over the arguments for why you might even need a server. There are many ways to add storage and to share storage over the network that don't involve a dedicated server. I'd like to toss in that having a dedicated server in some sort of RAID configuration that can recover from the catastrophic failure of a single drive does NOT mean you don't need to do backups. You can lose all the data on any kind of server either from some sort of physical catastrophe (fire, flood, earthquake) or from external attack (ransom ware). The only way to recover from those things is to have offline, preferably offsite, backups.
I had a WDC MyCloud EX2 for many years. Two 4GB HDDs, mirrored, for 4GB of usable storage. It was adequate for holding bulk data that was not used a lot (videos, etc.), data that I wanted to share on the network independent of any of the computers, and daily online backups of all my computers. It was slow and only had room for two hard drives. But it was inexpensive. I ultimately out-grew that device and recently upgraded to a Synology DS920+ with four 4GB drives in a RAID 5 configuration for 12GB of usable storage. The Synology is much faster and more capable (lots more optional and add-on features). But it was expensive and had a steeper learning curve for taking full advantage of it.
You can get a MyCloud for under $400 with disks included. If you want something more capable with slots for more disks, I'd recommend one of the Synology servers. In that case, you're looking at somewhere around $1200 and up. If you feel so inclined and think it's within your abilities, building your own server from an older computer you have lying around is probably the cheapest way to go. You don't need a lot of processing power or memory for a server. But pulling all the components together to make it work is time consuming.
|
|
|
|
|
|
Yes, and it's worth it for frequently used files and quick access backups that you and/or your family may want to keep around and share, but don't want to send into "the Cloud". Though in my case I then run backups/archives of those file server files that I do want to keep around into the Cloud!
For example, licensed software and keys, the iDevice media directories (just point iTunes to the mapped drive share and Bob's your uncle), photos and videos, the file share for the home theatre PC, and so on.
For years I've been pursuing a hand-me-down approach: generally my old PC lends its parts (motherboard, CPU, memory, every so often case and power supply) to upgrade the file server. The "unchangeables" in the FS are the hardware RAID controller with its disks in RAID10 configuration and a venerable USB stick that hold VMware ESX. So the actual server is a virtual machine. That way I can update the host machine without having to worry about having to reinstall! Older hardware gets a second lease on life instead of landfill!
The only time I ran into an issue was when the RAID adapter itself died and its a pretty old model. Bought a cheap knock-off of the Adaptec 5805-Z from China - and didn't even have to reconfigure! Just re-attach the disks and all was well again. Also, the odd dying hard disk, but that's exactly why you run RAID.
Now, should you have the privilege of gigabit Internet with no quota, then the whole equation may change: if you can get to files on the Internet as fast as most file servers, then that advantage disappears. Unless you then invest into a faster LAN.
Good luck!
|
|
|
|
|
|
TL;DR — the answer to your two questions is:
- Aye!
- For me, most definitely. Your mileage may vary. It all depends on what you need to do with your files, and what you expect from a NAS (compared to other alternatives).
Now for the (very) long and exhaustive reply...
It seems to me that I've 'always' had a file server in my home LAN. It started to be an old box just running Linux. Then, for many many years (well beyond its expected lifetime!), I had an Iomega Home Media Network Hard Drive (see Iomega Home Media Network Hard Drive Review - YouTube). It used just one single, pretty ordinary HDD, so after 5-6 years, when it started to fail, I could easily swap it by a new one and reinstall the Linux embedded system it had. Ironically, the hardest thing to replace was the mini-fan (I still have a spare or two lying around) which kept the whole thing cool...
Besides backups — mostly using Time Machine — I naturally used it as a home media server. It did its job well — especially for music — and already supported a few useful remote utilities (some of which required third-party VPN software, from a company that has long since ceased operations). But once you hacked it to get SSH access, you could pretty much do whatever you wished with the underlying Linux system. Alas, there wasn't really a lot you could do, since it didn't ship a compiler, and it wasn't that trivial to cross-compile things for the device (basically because of some proprietary libraries that had to be linked with). But there were still some things you could do. And, of course, there was always the choice of installing something like OpenWRT...
At some point, I managed to get it to store backups from my 'personal' server(s) running on data centres providing VPS and/or bare metal leased hardware, and vice-versa. It was a cheap way of getting reasonable backups from those server(s), and at least I would always have those backups stored where I could get at them easily. Imagine the worst-case scenario: the company hosting your remote server goes bankrupt or has a major fire that destroys their data centre, thus forcing them to abruptly cease operations, disconnecting all servers overnight, as well as wherever they used to back up them — and you're stuck. This didn't ever happen to me, of course, but knowing that I was prepared for such an eventuality let me sleep well at night (the reverse was also true: if our home got destroyed by an earthquake or a domestic fire, well, I'd still have remote copies of everything; thankfully, that didn't ever happen, either).
I really loved that device, but, alas, at some point in time, it had to be retired; but for a low-end, entry-level device, it was sturdily built and outlasted several of our computers.
Then, for a relatively short while, I got a second-hand Time Machine from Apple. Because it's a locked-in, fully proprietary system, there is nothing you can do what it that Apple didn't specify beforehand. I just used it for Time Machine backups and as a music server, and that was all it did, end of story. No fancy backups with remote devices and the like. Bummer!
As Apple incessantly brought out a new macOS version every year, their 'ancient' Time Machine product got less and less support beyond the 'bare essentials', i.e. making sure that critical security updates were still being delivered. But it was clear that Apple wasn't interested in supporting their old Time Machines any more, so, in truth, I actually used it for a relatively short period of time (in fact, I still have it, fully packed and operational, with the idea of selling it on eBay — which I keep forgetting to do so...). Also, at that time, I was getting used to using many redundant, free 'remote drive' services — DropBox, OneDrive, Google Drive, iCloud, you name it — as well as some self-managed services (such as Pydio) running on 'my' remote server. The major problem is that, from my perspective, all those managed services are insanely overpriced — for what I would need to pay for a full backup of my data in a year, I'd be able to afford a contemporary NAS. Granted, I could settle for just backing up a few, selected things. And that's what I was doing anyway, juggling with the free tier of several accounts, backing one folder here and the other there. Eventually, all of those got filled up quickly.
Also, if you have done that kind of account-juggling before, you know how tough it is to keep all those services running smoothly at the same time and not interfering with each other. I mean, you'll have all those processes constantly running and checking if anything on your disk has changed — and, if it did, see if it 'belongs' to 'their' folder. There would be conflicts, there would be hiccups, some things would get backed up while others silently failed (because, say, you had exhausted your free tier...). And my self-managed systems were never satisfactory: they were good for 'cold storage' (since, comparatively speaking, the cost per TByte on a remote, bare metal server is insignificant compared to, say, Google Drive or any of the others), but they didn't work so well for 'live' filesystems, mounted remotely — mostly because I wouldn't be able to afford enough bandwidth for that (at either side of the equation!).
In other words, it was not worth my time and patience to replicate the infrastructure of, say, Dropbox, just to avoid paying the dollars that Dropbox charged me for the extra space. There are always tradeoffs like that to consider. I could do it, sure, but could I do it cheaper than Dropbox? Honestly speaking, my answer would always be 'no', assuming that I wanted to fully replicate what Dropbox could offer me.
It was time to consider a new strategy, and that meant going for a new NAS for the home LAN. I had some requirements on my list: sure, I wanted something cheap — it would have to cost about what it would cost me to build a home Linux device, with, say, a Raspberry Pi, running OpenWRT or something similar — but reliable. I wanted full root access and the ability to do whatever I wished with it — but I didn't want to rely too much on having to tinker with it all the time just to keep it working: even though I love to spend my spare time (hah! ...as if I had that!) tinkering, I felt that it wasn't the correct approach for a device that I planned to use as a serious device for everyday backup storage.
It also meant having a considerably small form factor (no, I don't want to have huge boxes from former desktop PCs lying around), being sturdy (to survive my cats), silent (sorry, no more constant fan droning!) and be reasonably energy-efficient (old desktop PCs with decade-old power supplies are hardly that), since it would have to be running all the time, and drain some of the battery juice from the UPS, which should last long enough for a safe, controlled shutdown.
These days, with such requirements, there are literally hundreds of devices out there, from cheap Chinese manufacturers offering such devices for a handful of yuan, to professional storage systems from the Big Corps, who sometimes have Home Office versions of their devices (HP comes to mind). I'm pretty sure there are many excellent choices out there for a reasonable price, and I was stuck with the endless options, after the hours I spent reading all kinds of reviews (from professional magazines to Reddit subs), trying to figure out what was the 'best' device that would fulfill my expectations and that I could actually afford to buy.
Eventually, I settled on a Chinese brand — well, a Taiwanese, to be more precise (assuming that Chinese censors are not following this thread, remember, Taiwan is not the People's Republic of China, and they have been electronics giants well before China even aspired to become one) — which has been around since 2000 and knows the market well: Synology. To be truthful, they are a multinational, operating everywhere around the world, and that was also a deciding factor: instead of buying an off-the-shelf, no-brand device at the nearest computer spare parts shop, or going for something better but only available via online suppliers, Synology actually has a local branch here, offering their devices for a very good price (compared to getting it online!), but without the hassles of dealing with import taxes, customs bureaucracy, and carrier services delivering at the wrong place (or forgetting to properly update their tracking systems). This is naturally more important for devices that require some expertise in picking the 'best' combination of price/performance — namely, choosing wisely the HDD you buy with it — than with other devices, where the HDD/SDD is basically part of the product, and you just get what the manufacturer decided to be a good idea to put into it.
That was actually the reason I went to Synology's local branch. Aye, I had asked around in so-called 'speciality shops' for their competitors' products, but I quickly noticed that their reps lacked the expertise to properly answer complex questions. For them, a 4 TByte drive is just that, a 4 TByte drive. They might know the conceptual difference between a HDD and a SDD and assume that an SDD, having no moving parts, will be far faster, more silent, and more energy-efficient, and, as such, be more expensive; but that's where their knowledge ends.
Again, on the high-end, of course you'll have engineers lecturing you on the advantages of their multi-Petabyte system cooled by liquid nitrogen and which will tell you how precisely tuned the RPMs of their devices are, so that there are no vibrations, nor interference from the electromagnetic fields generated by each spinning disk, thus lowering the ratio of noise-to-signal when accessing each sector on the disk, which leads to making drives more reliable in the long run (if you haven't noticed: I'm making all that up). But these are priced beyond the money event horizon of a humble freelancer like myself.
Synology sort of fits well in the middle of those extremes. Sure, their lowest-priced devices come very close to look like off-the-shelf NAS, and offer similar features and reliability (well, at least you get better software...); while at the other end, Synology offers industry-class, data-centre-ready solutions for huge storage farms. Between both extremes, they have hundreds of choices — and thus a plethora of different prices! — which means that it isn't that easy to pick the 'best' product you need.
I actually had one specific product in mind before I knocked at the door of the branch office, but it took me just a few minutes to understand how limitless my ignorance of contemporary storage devices was. That was because the first question I was asked was what kind of disks I wanted to put in the device, and if I would buy them separately or not.
Because all I could think about disks was if they were HDD or SDD — I was going for SDD — and, in the case of HDD, I could only talk about how fast they spin, I soon got the experienced, benevolent smirk of a professional who knows very well that I require assistance — because, frankly, I had no idea of what I was saying.
In short, the point is that you can have any kind of disk (or even disk combinations) inside the Synology drive. Synology doesn't care; they aren't disk manufacturers, that's not their core business, and they don't get good margins reselling disks built by third parties. The reason why they are so happy to recommend different kinds of disks is because they have thoroughly tested most of them (at least the Big Brands) and evaluated them running in real environments (as well as on the lab, of course) inside their devices — not because they read the characteristics on the label. Naturally enough, they also collect the experience of their millions of customers, allowing them to figure out the precise combination that will work best for each class of customer, within their respective budget. I have to say that I was impressed by the massive amount of information their engineer gave me!
I cannot say that I have understood most of it, much less remember all the tiny details, but I can summarise it in a few sentences:
- NAS disks are meant to be constantly spinning, 24 hours a day; unlike desktop disks, which may get stopped now and then and be gently spun up again (mostly to conserve battery power on laptops).
- Even so-called 'server-class disks' might not be appropriate for a NAS: even servers will not be constantly accessing their disks (at least in theory), and the way they do it is optimised anyway. Sure, they will be 'constantly on' all the time, and thus place heavier demands on the disk, but a well-tuned server will have plenty of memory to cache whatever the kernel needs, and limit disk reads (and especially writes) to the bare minimum. It's just when an underpowered server relies on disk swap as opposed to memory that the disk gets stress-tested to its utter limits (and that's why 'server disks', unlike 'desktop disks', are manufactured differently).
- By contrast, NAS disks are working all the time. They will be fetching tiny files (measured in bytes) as well as huge ones (measured in GBytes), and the combination with which these will be fetched/written to is unpredictable. They will serve files for several different operating systems — thus, they will not have beforehand knowledge of which files to save in memory, or how to organise the filesystem so that it prioritises some files over others. That's the kind of data that, say, Windows, Linux, or macOS know beforehand — and organise disk space to make it more efficient (and that's why hard-core Linux sysadmins will also fine-tune things like partition tables, because they know that some things have to be served faster or more often than others). But a NAS will be dealing with files coming from all sorts of systems and cannot 'predict' what is the 'best' layout it needs. Consequently, the disks have no choice but to be always spinning.
- On a NAS, you expect 'network speed' to equate to 'disk speed'; in other words, if you have a Gigabit Ethernet LAN at home, you expect files to be transferred to and from the NAS at, well, Gigabit speeds (or what would be the point of having a Gigabit LAN in the first place?). To make matters a bit more complicated, if you have a small office (or all your family members have multiple computing devices), you expect that everybody is able to transfer files at Gigabit speeds — and that the NAS can handle them. Ideally, inside your LAN, you wish the LAN to be the bottleneck, not the NAS. But, on the other hand, it's also pointless to pay more for a faster system that is adequate for a 10Gbps Ethernet LAN if all you have is four computers with 1Gbps Ethernet cards. NAS disks, therefore, have to be able to handle 'wire speed' for your environment — and not all disks can handle that, or, if they can do it at 'peak performance', they might not be able to do it all the time.
- Finally — and against my own expectations! — SDD is not always better than HDD (in the sense of being faster, consuming less energy, and lasting longer). It's actually much more complex than that. Contemporary OSes have filesystems that have been redesigned to take into account the very different approach taken by SDDs compared to HDDs, and, under most scenarios — meaning: your desktop computer or your laptop — SDDs will almost always be better, faster, more energy-efficient, etc. They will also degrade differently over time, as bits of solid-state memory get 'burned' out and reassigned (this is not very different to what happens with the magnetic properties of a disk surface — everything degrades due to entropy, it's just a matter of how each material degrades, and what solution is adequate to deal with that degradation over time). The advantage of 'no moving parts' (which, mind you, is a huge advantage!) may be offset by the effects caused by heat dissipation — especially when talking about 'always on' systems that are under constant stress. The list goes on, and at the very least, I understood that there are still very good reasons why disk manufacturers haven't dumped all their HDD production lines and replaced them all with solid-state devices.
So, you see, there is far more to it than just 'deciding' on having a NAS at home as your LAN file server. The 'decision' is, naturally, the first part of a long journey, but there is so much more to it than simply clicking on a picture on Amazon.com and getting the NAS delivered to your home.
Synology NAS are, for the most part, Linux boxes. They run a special distro from Synology, called DSM (it just means 'Disk Station Manager'), mostly under ARM64 SoC solutions, but there are a few Intel CPU offerings on the higher end. The current version (DSM 7) is conceptually not much different than, say, a customised Debian solution; Synology has even started the long process of moving all their running services to be managed by systemd, like on other Un*x-based systems (I won't comment on the endless wars around systemd, but I can at least say that it's 'nice' to have something familiar running there — earlier DSM versions were a nightmare to figure out how the system was booted). DSM 7 is meant to be user-friendly, thus all package management and installation happens on a GUI running on a web page; you're not supposed to 'go under' the GUI and tinker with the system. But you can, and, unlike other manufacturers, Synology won't care, they won't threat you with loss of warranty or anything else, and they'll even give you the tools to best tinker with your system (most of which are released as open source, anyway — due to GPL licensing requirements on many of the software components).
Last but not least, and besides the extensive methods of accessing the NAS at home in a secure way (from using ssh, to several types of VPNs, to weird redirecting systems that act as dynamic DNS servers, or a simple, plain, HTML page, from where you can share links just like under Dropbox/Google Drive/OneDrive/etc., there are plenty of choices — and you get them all included, not counting with a few ones that can be installed from the community packages repository), what actually 'sold' me to the way Synology does things was something that is (currently) called 'Cloud Sync' (it's been offered under different names). This is nothing extraordinary — you can do something similar using rclone — but the GUI is quite helpful: a way to list all (well, almost all) your multiple accounts on different cloud storage providers and set them all up to sync with different folders (or partitions, or disks...) — simultaneously.
Ultimately, that fixed for me the 'multiple cloud providers' nightmare, which required me to use several different apps on my ancient MacBook Pro — and it wasn't trivial to set up multiple accounts per provider. So, nowadays, all I need to do is to sync the MacBook Pro with the Synology NAS; it'll be up to the NAS to figure out which folders are to be synced with which provider. That happens automatically, without my intervention, and without needing to worry if all's working well or not. That's up to the NAS to figure out. Oh, and aye, S3 storage can also be synced, together with all the other possible providers — so if your preferred provider isn't listed, but you happen to know that they also expose a S3 API (as it happens with some open-source solutions, such as Pydio Cells), then you can also sync with it.
It allows me to do an insane configuration to share — in real time — files among different people, across different platforms, according to each person's favourite sharing/syncing tool of choice. Here is my example: my partner and I work together with a friend in NY, across the Atlantic (from our perspective). I favour the Synology NAS as the 'preferred' syncing platform, and Pydio Cells (currently running on an external server) next. My partner uses almost exclusively OneDrive for all her needs (she's got a Terabyte with her Office 365 subscription, so it's worth using it), although often she also uses iCloud and even Adobe's Creative Cloud. On the other hand, our friend in NY is exclusively a Google fanboy — even though he runs Google Drive on a Mac. We're an ocean apart, so that means that the 'trivial' solution — get everybody to sync with our home NAS — may not be a solution. Also, my partner has two computers, and needs quick syncing between them; one of that computer is a laptop, meaning that she needs to be able to safely and securely do her syncs even when outside the comfort & security of our home LAN. On top of that, it's far more likely that corporate or campus networks (where she sometimes needs to work) will have open connections to OneDrive or Google Drive, but not to, say, our home NAS. Last but not least, even though we have a 0.5 Gbps connection at home over fibre-to-the-home, and it is seldom congested, that doesn't mean that, outside our provider, things will work that smoothly. That is even more true for our NY friend, of course.
So... here's what I did. First, I've synced my own personal OneDrive folders with the Synology NAS (mostly for testing purposes, originally I had not many files stored there). Because our friend needed access to our business files, those folders would get synced between the NAS and Pydio Cells on the remote server (which, mind you, is somewhere in Germany, and boasts excellent Internet connectivity, even when accessed from the US), thus allowing my friend to get easy access to them (he does have a login on our Synology NAS, but he uses that only as a last recourse, because of the above-mentioned difficulties — it's not only about bandwidth, which we have in spades, but also traffic, jitter, upstream congestion, providers deliberately dropping packets, and so forth). You might ask why I didn't simply share those folders on OneDrive with my friend in NY. Well, it so happens that this is trickier to do than it should — one thing is to share individual files (or even folders), especially with read-only protection; the other thing is to share collections of folders, synced in real time, with someone who does not have a Microsoft account, and, most importantly, is not even part of our 'family account'. In fact, Microsoft is very generous with their storage space — each family member gets their own 1 TByte — but, sadly, you cannot share that space directly with the other family members. That's something allegedly only possible under their so-called 'business' accounts. There are lots of explanations elsewhere regarding the very confusing way Microsoft handles 'individual', 'family', and 'business' accounts: originally, these were completely different and separate services which did not interoperate. They still don't — Microsoft basically just gave them identical interfaces (in terms of look & feel, that is). Beneath the hood, however, things are completely different. Thus, you cannot have a 'friend of the family' kind of account; neither can you directly share storage space between family members; etc. The limitations are more annoying than critical, however; despite those limitations, their service is still worth the cost and is currently very reliable.
That means that there are two 'master' copies of all our data: one is on our home Synology NAS; the other is on the external server, running Pydio Cells. For my partner, all business-related folders are exported via OneDrive to her account, so she can access them wherever she wishes; for me, I sort of get them in many different ways (I'm the oddity!), but usually I just worry about my local folder, which just happens to get synced to the NAS (note that Synology allows remote syncing as well — it's weird, but it just happens to work, and work well, without any extra configuration; besides that, obviously Synology is also in the cloud storage business, and they essentially offer the same services as Microsoft/Google/Dropbox/Apple/Yandex etc. etc. — with the slight advantage of being able to do much closer integration with their NAS). Finally, my friend gets access to those files via Pydio Cells, and whatever he stores that will be remotely synced to our NAS in real time (aye, I use rclone for that!), and, from there, it goes to OneDrive...
You might ask if the access to individual files might be way too slow for my friend to access on a server in Germany. Well, yes and no. You see, there are a lots of 'tricks of the trade' here: the external server is actually not directly accessible from the Internet. Rather, it is wrapped under Cloudflare. For those who are really clueless about Cloudflare, they are perhaps the largest 'distributed remote proxy' in the world (not the richest, though — most of their services are actually for free, although the paid services are very cheap and extraordinary). If you're familiar with remote proxies, it should be easy to picture how Cloudflare works: they essentially provide a layer in front of one's web server that will not only filter out potential attacks of all sorts, but also cache (mostly) static files, without even revealing the IP address of your server. This is pretty much what any other Content Delivery Network (CDN) offers to a certain extent. The beauty of being distributed means that people connecting to your server will actually be downloading files from the nearest node of the CDN, as opposed to going all the way through the Internet until they hit your server. Cloudflare adds a lot of bells and whistles to the package (they basically create a superfast 'tunnel' across the Internet between their multiple nodes, which, these days, are numbered in the dozens if not hundreds — all of which hosted on secure data centres with unlimited bandwidth and gazillions of servers), but the principle is the same: the idea is that my friend in NY will, in most cases, not download files directly from the server in Germany. Rather, his system will contact the nearest node in NY and request a copy of the file, to be served locally (and, thus, avoiding the expensive trip over the Atlantic). On the German side, something similar happens: Cloudflare caches that file on their node there, and, basically, it's just the two nodes inside Cloudflare's network that exchange data — if needed. In practice, of course, this is not perfect in the scenario where there is only one file to be transferred by one person; but you get the point. The beauty is that, if and when my German server goes down (say, because I've just upgraded its Linux kernel), my friend in NY will never notice it — Cloudflare will serve any files cached from my server before it went down. Simple!
Actually, the biggest difference between Cloudflare and all major CDN providers is just that Cloudflare hides its existence — from the perspective of both those who are writing content and those who are retrieving it. With common CDNs — the oldest was perhaps Akamai — you will have to upload all data to a 'special' place on the CDN provider, from where people will be able to download it from the nearest node. So, if you have a file usually accessed via https://my.site.com/my-picture.png, you will have to rewrite that to something such as https://cdn-provider.com/my-site/my-picture.png. Each provider does this slightly differently, and most of it is automated anyway. The best example is perhaps Automattic's Photon CDN. Automattic is the company behind WordPress. They have also their own CDN for JPEG and PNG images, a service they offer for free, so long as you install their Jetpack plugin. Jetpack will automagically rewrite all URLs to go through Photon instead; the user uploading the image to their WordPress backoffice isn't even aware of what is actually happening. They will only notice that the images they've placed on their article will not be served from the web server's address, but rather from somewhere under wordpress.com. As a user of the free service, you have no real control over what happens, or how the URLs will look like (WordPress may change them anyway without notice). But you won't really care; what matters is that these images will now be hosted by WordPress, which will bear the burden of wasting bandwidth to serve them — and not you (but you'll always have a local copy — if you turn Jetpack off, no data will ever be lost. The links to those images will simply revert to URLs pointing again to your server instead).
Cloudflare, on the other hand, is completely transparent. You don't need to do anything on your server to make it 'Cloudflare-compatible' or even 'Cloudflare-aware'. From your perspective, you're just accessing your own server, with your own URL schemes, with the files exactly where you placed them and with the URLs you decided that worked best for SEO. From the perspective of a visitor, they will have exactly the same experience: nothing will have changed for them. The difference is subtle: your web server will actually appear to have a Cloudflare IP address! But except for the IP address, everything is completely transparent, and it 'just works'.
That's unquestionably a major plus if you host your own remote file server with lots of (static!) files and expect those to be retrieved from lots of people from across the globe.
But there is more! Cloudflare actually works by hosting the DNS records for your domain (another free service they offer). As such, if you use some sort of dynamic DNS to expose the IP address of your home NAS to the Internet, you can enjoy the benefits of Cloudflare for your server as well. Cloudflare couldn't care less if the IP address of your home NAS changes every other day or so — or even every hour, or several times for hour. A simple script that detects any IP address change from your provider can, thanks to Cloudflare's API, very easily update the DNS. Sure, when the IP address is actually being changed, there will be a small hiccup until Cloudflare picks up the new address. But who cares? Cloudflare will already have cached your files and is serving them from their nodes anyway! So you can host your own websites on the NAS without the fear of having too little bandwidth for that, or worrying about IP address changes, or even if your NAS goes down (say, because of a power failure!).
And, in fact, that's why the community has packaged popular web service apps to run on your NAS — from WordPress to all sorts of Internet radios, or even Plex for multimedia: you can install all of those on the NAS — it is, after all, a regular Linux box! — and rely upon Cloudflare to keep a persistent URL to all those services you provide. No need to lease a remote server, or a virtual private server, or even plain, old, shared web space — just use your NAS for that! Cool, right? 
Ok, well, a few words of caution.
Everything I described above comes with its own caveats, of course. First and foremost, your Internet provider may prevent you from hosting services on your own home NAS — make sure you've read their Terms of Service first!
Secondly, and perhaps most importantly, while these things are technically possible, it doesn't mean that you should implement them on your NAS. There is at least a very good reason for that: CPU power.
You see, NAS such as those by Synology are fine-tuned to serve files over a LAN at wire speed. That means that things such as the CPU, the available memory, and whatever hardware tricks have been put on the motherboard, have that purpose in mind: the NAS is not meant to be a general-purpose server, but rather a very specialised device that does one thing, and does it very well: archive your data at blazing speed and with security. Everything that is not directly related to that will probably suffer from performance issues.
Granted, this is 2022, and the NAS manufacturers are paying close attention to what people actually use their NAS for. Even my humble Iomega drive was thought to be a 'home multimedia server'. As such, while its early-generation, ARM-based CPU was vastly underpowered, it already had some board logic to handle audio and even video streaming. In other words, things requiring compressing and decompressing audio/video streams were considered part of the package, and, as such, they were optimised (within limits) so that they could work reasonably well in a home LAN scenario.
Synology, just like other companies in the business, does the same to some of their NAS — those that they specifically label as being 'multimedia-ready'. That essentially means that there is some extra help from the motherboard to help processing streaming data. There might also be some crypto chips to deal with the number crunching required to store all data on the disk(s) encrypted — a common trend these days — without incurring in a loss of performance. Because users expect that their data gets encrypted 'instantly', the NAS needs to address that. But instead of relying on a more powerful, general-purpose CPU for that — which will undoubtedly cost much more! — they stick to a well-proven, low-end CPU (such as those with an ARM architecture!) and rely on external chips to do the heavy-duty number-crunching.
What does this mean in practice? Well, my own experience with the Synology NAS is very surreal in that regard. File access over the LAN is much faster than expected: faster, in fact, than if I had connected some external disk directly to my Mac. That's not really a surprise: the Mac is not fine-tuned as a file server, and there is a limit to the bandwidth available to directly connect an external disk (remember, I have an old MacBook Pro, which lacks latest-generation connections — but it has a Gigabit Ethernet!). It makes little difference how I access files on the NAS: be it via direct file transfer, using the Samba protocol, Apple's own protocol (now deprecated), NFS, the Time Machine... that's all irrelevant, it will go up to wire speed in all those cases, while at the same time silently transferring data to my external server as well as to OneDrive, Google Drive, Dropbox, and Yandex Drive at least. Granted, all those services are not always running. But they're way more often than you might imagine: your contemporary personal computer, be it a Mac or a PC running Windows or Linux or FreeBSD or whatever you wish, are all constantly reading and writing small files to disk. These can be logs, or some kind of status files, or saving the desktop layout, or, well, doing (local) filesystem maintenance, such as preparing to sync with external services — or simply to deal with versioning, filesystem journaling, and/or constant snapshots of what has changed for subsequent backups. All of these may be carried out in memory, but eventually need to be written on disk (or SSD) as files. Each time a file gets written on disk, it gets potentially pushed over the wire to be synced. Some folders may be excluded (such as caches), but even a 'normal' folder, which apparently just has untouched files with your content (say Word documents and/or pictures taken with your camera), will be constantly writing tiny amounts of bytes to the disk, even if you don't 'see' anything happening. It may be just under-the-hood compression/decompression — or encryption/decryption. It may be the operating system pre-generating thumbnails for the pictures. It might be the search system, pre-indexing all those files, so that when you actually need to do a search, that information has already been compiled. It might be a subsystem evaluating the integrity of those files, to see if they have been compromised by a virus or other malware. There is really a lot going on, which affects the filesystem in one way or another, and all of that will be constantly generating some files (even if only tiny ones!) that have to be carried over by the Ethernet LAN to be saved/synced/backed up by the NAS.
And don't forget that the NAS is essentially a Linux server; as such, all those maintenance tasks that are constantly running on your laptop/desktop will also happen on the NAS as well. The NAS needs to juggle between its own maintenance tasks and actually storing and serving files to the computers on the LAN. On top of that, of course, I've added all my complex synchronisation rules with both my remote server as well as a plethora of cloud storage providers. There is really a lot going on — and it goes on all the time. Actually, you might imagine that 'nothing happens' when you go away from your computer for a while, but that's not the case. The screensaver being launched will need to fetch files from disk. Even if your screensaver is just a blank screen, the operating system will be running other maintenance tasks constantly — and probably even more so if you aren't doing anything: contemporary desktop operating systems just work that way, prioritising tasks according to the demands of the user, who will be launching applications and opening and writing files actively. Sure, if you shut down your computer, you'll cease all that wire chatter. But that doesn't mean that the NAS will have nothing to do! Instead, when it notices a decrease in network traffic, it turns on its heavy-duty maintenance tasks, and prioritises them. In the case of the Synology DSM operating system, that means quite a lot of things, many of which are under your direct control: for instance, how 'deep' the built-in search engine should go. At some point, if it has enough time for that (because, well, you're asleep with all home computers shut down), it will even search and index Word files, PDFs, and so forth — or even the lyrics embedded in MP3 files. It will tag everything it finds and store it on a database that is being constantly updated (Synology mostly uses a Postgres database, but it also runs Redis and a few other systems you'd expect to see deployed on data centre-grade servers, not on a humble embedded device at home). Simultaneously, it also checks all files for virus and malware, checks the integrity of the DSM core files (to make sure they haven't been tampered with!), and, well, compiles a lot of statistics — most of which you won't be even looking at, at least not on a regular basis, but on the remote possibility of you ever wishing to see some performance graphs, or how the disk temperature has evolved over time, well, the data has to be there first, already processed to be available on demand, if and when it is needed.
On top of that, of course, I watch videos and series and listen to music and/or podcasts. Podcasts which, by the way, obviously need to be downloaded first. I expect that the multimedia experience is not only satisfying — no stuttering, no weird pauses, no 'spinning disks' while waiting for a stream to start — but, simultaneously, I expect to be able to continue to do my work and get real-time backups.
Even under such circumstances, the Synology NAS doesn't miss a beat. Or a byte. Whatever. It just runs. When I first read the instructions for Plex, and figured out the insane amount of 'background tasks' that it actually runs — from adjusting streams and potentially re-encoding them for different devices (say, a cellular phone as opposed to a widescreen TV), to checking for the daily schedule for IPTV channels, to downloading podcasts, to gathering trailers and music demos that its algorithms deem to be 'interesting' according to my tastes (which means profiling my multimedia consumption and then download the appropriate content...), there is an absurd amount of work being done on the background — even when I'm not watching or listening to anything!
I thought that there was no way a humble ARM-based, system-on-chip, off-the-shelf CPU could handle all that.
Oh yes, it does.
And with lots of resources to spare! For example, except during some beta-testing (when I just tried out a few quite unstable features/applications under development), I never saw the dreaded 'out of memory' message. I never saw the NAS reboot just because it exhausted its resources. I saw CPU usage going eye-poppingly high, to the point that I thought that the server would overheat and get bricked, but that had little or no consequence — during those bursts of intense CPU usage, the Web interface for DSM would all but freeze, while typing in an open SSH session to the NAS would only show up after half a minute, but... did it slow down that 'urgent' file transfer I desperately needed to finish to meet a deadline? No. It just kept downloading at the same speed it started with, no matter how 'busy' the CPU was.
There was a lesson learned that day. A well-tuned NAS is meant to do a single job very well, and only that. Nothing will stop the NAS on its tracks when it's handling files — because that's what it was designed to do, and do well. On the flip side of the coin, sure, you can do heavy-duty C compilations (with full optimisation turned on, of course) on it, but don't expect the CPU to be able to handle it. It simply wasn't designed to do that. In fact, I wondered why it was so hard to get a reasonably recent C compiler package for the Synology DSM. The reason is simple: it was never meant to be a 'development environment', and, as such, it will handle such tasks terribly. In fact, on the documentation, Synology clearly states that you should never compile anything on the NAS — rely on cross-compilation instead (that is apparently how their own programmers do it, and, well, they've been working on DSM for two decades now, so I guess they know what they're talking about).
Granted, over the months (a few years now!), I obviously pushed the NAS to the limits, in terms of 'doing what it was never designed for'. And that's why I say that my experience is a bit surreal. All tasks that are actually related to serving files from disk are uncannily fast, faster than on any other machine I have put my hands on. It seems like there is nothing fileserver-related you can throw at the NAS to make it even tremble; it's as if it has unlimited resources for serving files. On the other hand, though, get it to compile a handful of lines of code, or PGP-decrypt a message, or something which, albeit certainly CPU-intensive, is not overwhelmingly so — at least, not on a general-purpose Linux server! — and you'll get the NAS on its knees begging for mercy.
It will still serve files, though. That's the amazing bit behind those specialised devices!
Disclaimer: No, no, I don't work for either Synology nor for any of its subsidiaries.
|
|
|
|
|
Starting tomorrow, republics enter a truce, yes? (6)
I think this style is not used here thus far. So may be think different.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Treaty ?
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|
|
That was really quick! And yes, you are right. Congratulations!
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
Solution for the rest of us please.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
Take the initial letter of each word after "Starting".
|
|
|
|
|
As Richard said. First letter of each word and phrase also contains the meaning in it. Inspired from acrostic poems.
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
And a nice clue. Although it is quite rare for me to get the answer before @OriginalGriff or @pkfox, who are the masters of CCC.
|
|
|
|
|
I didn't even get a chance to see it before Pete solved it! 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks. I am quite proud of myself. 
"It is easy to decipher extraterrestrial signals after deciphering Javascript and VB6 themselves.", ISanti[ ^]
|
|
|
|
|
|
|
Good. NPMs are the QA of the "professional" """developers""". Codez urgentz plz.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
That's been my beef for decades with open source projects. No ownership. No liability.
But then the fanboys try to spin it into a positive thing. If you're not happy, you have the source and can fix it yourself! How awesome. I'm now also responsible for someone's abandoned pet project.
Save me the "then pay someone for it" diatribe--in that case, it may as well be closed-source. Because as a developer who's got a schedule to meet, whether it's open source or not is irrelevant.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
