|
Backblaze B2 is the best deal I was able to find. 42TB is a lot of data though, this might be a situation where you put a box of HDDs in the attic of a friend that lives on the other side of the country.
|
# ? Jun 14, 2020 19:57 |
|
|
# ? Jun 5, 2024 06:41 |
|
I have the same issue but no solution. In my case I own discs for my entire collection, so my backups are the original media.
|
# ? Jun 14, 2020 19:57 |
|
Google apps business account with duplicacy and rclone.
|
# ? Jun 14, 2020 20:00 |
|
Brain Issues posted:What are you guys using for offsite backup that doesn't destroy your wallet? My opinion is most files are easy to redownload through usenet/torrent/whatever so that if you just backup the stuff that's difficult to get you're saving yourself a lot of money/time. That rip of Breaking Bad? You don't need a backup. Game of Thrones? You don't need a backup. That series you had to grab from youtube because it doesn't seem to be anywhere else? Yeah that might be worth backing up. Duck and Cover fucked around with this message at 20:20 on Jun 14, 2020 |
# ? Jun 14, 2020 20:17 |
Brain Issues posted:What are you guys using for offsite backup that doesn't destroy your wallet? Backblaze B2. I have about 10TB up there and it costs me about $50/mo. It took months to do the initial upload.
|
|
# ? Jun 14, 2020 20:24 |
|
Brain Issues posted:What are you guys using for offsite backup that doesn't destroy your wallet?
|
# ? Jun 14, 2020 20:26 |
|
In my opinion yeah. As long as your list of ISOs is safe, I don't care too much about actually losing anything on the NAS.
|
# ? Jun 14, 2020 20:33 |
|
Brain Issues posted:What are you guys using for offsite backup that doesn't destroy your wallet? Backblaze is another option, but that'd cost over 2 grand for the first year. Pretty pricey, still. https://www.backblaze.com/b2/cloud-storage-pricing.html#calculator
|
# ? Jun 14, 2020 21:41 |
|
Don't backup your linux ISO's unless it's literally irreplaceable, in which case I would just find the data hoarder at your office and give it to them. Backup your pictures and your documents, but your 41.99TB of <whatever awful media> ? Don't.
|
# ? Jun 14, 2020 21:56 |
|
DrDork posted:However, buried near the start of the questioning was a notion of slowly expanding the array as more drives are needed / bigger drives get cheaper, and that's the one thing RAIDZ basically can't do in an economical way. I probably worded it poorly, but by 'expanding the array' I was talking about increasing drive size, not number of drives. DrDork posted:
This was my original assumption, that all the drives just kind of blobbed together and I could Borg-like add new storage whenever. Obviously that isn't the case, and I assume has a lot to do with the other features that makes ZFS so good at everything else. That's why I kept looking for ways to start things off with a larger drive count without dropping 1000+ all at once. I may just split the difference and go with 8 drives. My parents have started making noises about 'cutting the cable' which has led me to research a lot of apps that end in 'rr'. I'm probably never going to be a power user compared to most other people who have gone to the trouble to build their own NAS, but the prospect of becoming a home DVR service does potentially increase my future disk use requirements. An unrelated question, do any of you use use a Windows 10 VM from your NAS? Or is there some online calculator I can use to estimate the resource requirements to use a VM as a daily driver? Some of the PCs around here are becoming due for a rebuild, if I could virtualize them and just serve them up through a cheap linux laptop connected to a monitor that would be a lot cheaper than buying/building another whole PC. But I didn't really build the NAS with that in mind, so I'm currently just rocking a X3440 and 16GB RAM in a SuperMicro S8XLI. The PC in question would just be doing office work and YouTube with some light photo/video editing, doesn't need to be a gaming rig.
|
# ? Jun 14, 2020 22:06 |
|
Zorak of Michigan posted:I have the same issue but no solution. In my case I own discs for my entire collection, so my backups are the original media. Same that my media is all off physical discs, but I still backup the library to the cheapest 8tb elements externals and keep them in a storage unit just in case. I cant imagine the work (time) involved to re-rip everything if I oops i accidentally'd my library
|
# ? Jun 14, 2020 22:16 |
I'm not sure if I'm brilliant or stupid, but I just thought of putting the new 'special' vdev, containing metadata from a secondary zpool of 15 disks in raidz3, on a zvol, possibly with checksumming, compression and caching disabled, belonging to a primary zpool consisting of four fast disks striped mirrors..
|
|
# ? Jun 14, 2020 22:58 |
|
You lost me at metadata and checksumming disabled.
|
# ? Jun 15, 2020 04:56 |
|
Your post made me wonder - sometimes people do a thing where they know they’re going to expand an array and so they temporarily set up multiple vdevs on a single disk using lvm or similar. Why can’t you take that idea to the max and set up a “meta layer” where zfs runs on a multitude of small mirror vdevs (let’s say hundreds) with the logical volumes inside the mirror vdevs scattered across the drives for redundancy - essentially a second layer of striping where the stripes themselves are moveable. This would let you expand an array simply by moving some of the vdev mirrors to the new disk and then expanding them (both the ones you moved and the ones you left behind). Space efficiency might not be 100% but surely a lot better than having to upgrade 8 disks at a time, or the “redirects” solution in the official array expansion code that permanently leaves you with O(N) additional disk reads for everything on the pool in perpetuity. If instead of using lvm or similar, you had the vdevs as non-mirrored files on a pool with redundancy, then you wouldn’t even have to have full mirrors. Performance probably wouldn’t be as great but again, enterprise doesn’t care about dropping 8 drives at a time for expansion, it might still be fast enough for home users. The alternative isn’t ideal either. Obviously the tooling for working with that arrangement safely doesn’t exist, but I don’t see any technical reason it wouldn’t work. Perhaps ZFS is not really optimized for handling pools with hundreds/thousands of vdevs though? Paul MaudDib fucked around with this message at 05:17 on Jun 15, 2020 |
# ? Jun 15, 2020 05:04 |
|
Brain Issues posted:What are you guys using for offsite backup that doesn't destroy your wallet? Selective backups of important materials. Aka not your entire Plex library.
|
# ? Jun 15, 2020 06:45 |
|
I've recommended and done this myself, getting another Synology unit, since well you indicated you have a DS1618+ and doing the backup on site for the first one, this means that any backups after that already have the majority of the data done, and will be tiny. Then give it to your parents, siblings, or close friends, and have it update weekly. Unless your data grows a lot between sessions, at most you will transfer a few gigs per month. You can pay them back by allowing them access to your plex, or whatever, i know a lot of people not tech savvy enough to delve into this stuff, and they really are amazed by it. If your data is growing terabytes per month, I am yeah, then you will hit bottlenecks no matter what, and having a local backup at the very least is best. There are a few that are fireproof and the like. One actually runs off a licensed version of synology operating system, if you want to make sure it is all the same: https://iosafe.com/
|
# ? Jun 15, 2020 06:57 |
|
H110Hawk posted:Don't backup your linux ISO's unless it's literally irreplaceable, in which case I would just find the data hoarder at your office and give it to them. Backup your pictures and your documents, but your 41.99TB of <whatever awful media> ? Don't. What? This OSX installer for VLC 0.7.2 from July 2001 is irreplaceable, how dare you sir Also that Google Earth installer from 2011
|
# ? Jun 15, 2020 08:43 |
Zorak of Michigan posted:You lost me at metadata and checksumming disabled. Paul MaudDib posted:Your post made me wonder - sometimes people do a thing where they know they’re going to expand an array and so they temporarily set up multiple vdevs on a single disk using lvm or similar. In fact, the basics of it is how the UEFI boot partition + FreeBSD root on ZFS partition is layed out in bsdinstall, which is done in the Almquist shell. With FreeBSD, a GEOM class can be layered any way you want, and since a partition is just a GEOM class via the gpart provider, you can absolutely create hundreds or thousands of partitions, as long as each one is above 64MB (that's the minimum size, which is also the reason you can't do ZFS on floppies - ZFS on floppies has come up more than once..). I suspect if there's a maximum number of devices that can be in a vdev, it's likely (2^64)-1 - ZFS doesn't really use datatypes below that. The "proper" way to expand a pool is to add a new vdev and simply do zfs send | receive on the local pool to redistribute the data onto the new disks - effectively what block pointer rewrite would do for raidz expansion. Block pointer rewrite isn't likely to happen, though - because as Matt Ahrens put it in a recent ZFS BoF at BSDCan, block pointer rewrite would be the final feature added to ZFS, since it complicates everything so massively. With FreeBSD, you can even use the GEOM classes ggated and ggatec to share GEOM classes over the network, so I imagine you could do some sort of clustering, if you took the time to write the scripts for setting it up. Another trick with GEOM is when you have a single disk with any filesystem on it in a machine, and want to add raidzN, what you can do is: Load the geom_zero kernel module (which writes and reads from /dev/null), create a zpool raidzN of some number of disks as well as the geom_zero device, then once you've moved the contents of the single harddisk over to the new pool, you do zpool replace tank geom_zero-device new-device. BlankSystemDaemon fucked around with this message at 11:07 on Jun 15, 2020 |
|
# ? Jun 15, 2020 09:02 |
|
D. Ebdrup posted:The 'special' vdev already does checksumming, compression, and caching on its own, which is why I was thinking it would be smart to not go through those codepaths twice. Does send | receive onto the same pool actually work? That seems pretty crazy
|
# ? Jun 15, 2020 20:07 |
VostokProgram posted:Does send | receive onto the same pool actually work? That seems pretty crazy ZFS is pooled storage consisting of DMU nodes with types such as block storage or filesystems provided by the ZFS POSIX layer, the same way memory is pooled by the MMU. Of course they can be copied around by zfs send | receive. What you're essentially saying is "copying things around in memory is crazy".
|
|
# ? Jun 15, 2020 22:29 |
|
The question in my mind is, does it work if the pool is over 50% full? And if so, does it actually rebalance / possibly defragment the data in a meaningful way?
|
# ? Jun 16, 2020 00:53 |
|
So I am waiting on parts for an uNRAID build that I will be putting together this week and am trying to think about how I want to do my 7TBish migration to it when it's complete, and then re-use the existing 10TB drive that the above 7TB lives on in the new unRAID pool. I have 2x10TB drives coming, and the (in use) 10TB that my media currently lives on. Does this sound like a proper plan? 1) Build the drat thing 2) Create a 1 drive + 1 parity drive pool (so, use 2x10TB drives that are new, resulting in 10TB of usable space) 3) Copy all the media to that newly created network share 4) Make sure the media copied and is all safe and sound on the unRAID box. 5) Yank the old 10TB out of its existing home, format it and add it (??) as additional capacity for the above 1+1 pool 6) Profit? Is there a better/safer way to do this?
|
# ? Jun 16, 2020 01:36 |
|
cr0y posted:So I am waiting on parts for an uNRAID build that I will be putting together this week and am trying to think about how I want to do my 7TBish migration to it when it's complete, and then re-use the existing 10TB drive that the above 7TB lives on in the new unRAID pool. I have 2x10TB drives coming, and the (in use) 10TB that my media currently lives on. I believe the thread will tell you keep the old 10TB as an off-site backup. Add to the pool when you can afford an additional 10TB. But it depends what other backups you have.
|
# ? Jun 16, 2020 01:43 |
|
Smashing Link posted:I believe the thread will tell you keep the old 10TB as an off-site backup. Add to the pool when you can afford an additional 10TB. But it depends what other backups you have. It's all basically replaceable downloaded poo poo. Everything important has a couple copies elsewhere in the world. Basically I want to be able to tolerate a failed drive, if my house burns down I have bigger concerns. cr0y fucked around with this message at 01:49 on Jun 16, 2020 |
# ? Jun 16, 2020 01:47 |
|
Seems fine since you've got a back-up of the irreplaceable stuff.
|
# ? Jun 16, 2020 01:58 |
|
Leave the parity off while you're doing the initial copying over and turn it on afterwards, parity calculations will slow down your transfer. edit: and disable your cache for any shares you're copying to as well THF13 fucked around with this message at 03:19 on Jun 16, 2020 |
# ? Jun 16, 2020 02:11 |
|
I also use B2. But I don't backup my Movie/TV rips only my personal files and my music collection. I held onto all those CDs but I never want to rip them again (FLAC on em), nor try and reassemble and musicbrainz all the downloaded stuff.
|
# ? Jun 16, 2020 05:16 |
|
THF13 posted:Leave the parity off while you're doing the initial copying over and turn it on afterwards, parity calculations will slow down your transfer. If you set your minimum free space/share split levels right, you don't need to micromanage turning cache off on ingest. If minimum free space is set correctly, it'll write past the cache when the cache is full. Plus its good practice to get them set right to begin with avoiding problems down the line if you ever write >cache size and haven't planned ahead for it
|
# ? Jun 16, 2020 05:36 |
|
D. Ebdrup posted:I'm having a hard time answering this, because it seems like a pretty fundamental misconception is going on here. Well what happens to the old blocks when the copies are written to the pool? Do I now have 2x everything in the pool?
|
# ? Jun 16, 2020 06:56 |
IOwnCalculus posted:The question in my mind is, does it work if the pool is over 50% full? And if so, does it actually rebalance / possibly defragment the data in a meaningful way? THF13 posted:Leave the parity off while you're doing the initial copying over and turn it on afterwards, parity calculations will slow down your transfer. VostokProgram posted:Well what happens to the old blocks when the copies are written to the pool? Do I now have 2x everything in the pool?
|
|
# ? Jun 16, 2020 09:53 |
|
quote:Yeah, who would want such a silly thing as parity calculations? Who needs them, what've they ever done for us, et cetera.
|
# ? Jun 16, 2020 14:26 |
And yet the thing most people worry about when replacing a drive in distributed parity situation is UREs, despite having backups, because rebuilding from backup is inevitably a week-long thing at least. Always assuming, of course, that people know their backups to be good - something most people with homelabs don't even know, let alone everyone else.
|
|
# ? Jun 16, 2020 18:21 |
|
The Milkman posted:I also use B2. But I don't backup my Movie/TV rips only my personal files and my music collection. I held onto all those CDs but I never want to rip them again (FLAC on em), nor try and reassemble and musicbrainz all the downloaded stuff. Yeah music I have like 3 copies of at all times.
|
# ? Jun 16, 2020 21:19 |
|
D. Ebdrup posted:The question is, why the gently caress do you have one dataset taking up more than 50% of your pool when you could have hundreds of thousands. Newing up a filesystem for every different, ah, "Linux distro" you want to preserve on your NAS isn't going to occur to most people, including me!
|
# ? Jun 17, 2020 17:04 |
Munkeymon posted:Newing up a filesystem for every different, ah, "Linux distro" you want to preserve on your NAS isn't going to occur to most people, including me! It disappeared completely with zfs, because 'zfs create' and 'mkdir' both accept -p, and 'zfs create' also lets you specify zfs-specific options via -o parameter=value like 'mount' and 'newfs' use.
|
|
# ? Jun 17, 2020 19:47 |
I'm in the process of setting up my new NAS to migrate from NAS4Free over to FreeNAS. Previously with NAS4Free, I just had my fletch_vdev pool with no datasets, and the /mnt/fletch_vdev was shared via Samba for my Windows machine. Over in FreeNAS, it will let me share /mnt/fletch_vdev via Samba, but it won't let me set ACLs after that. Reading more about it, apparently I should have been using ZFS Datasets this whole time. Then I can setup a Samba share for each Dataset and control the ACLs that way. I thought about just creating one big dataset, but after reading more about datasets I think it makes sense to break up my data into a few different ones, so I have more flexibility with snapshots and of course the ACLs. I was planning on using zfs send/recv with nc to send it over the wire. To facilitate that, on my old NAS I created the datasets and started moving the files around, then I can do the zfs send/recv on each of the datasets. I had just about completed that part on the old NAS when I noticed it started going very very slow. Sure enough: code:
code:
|
|
# ? Jun 17, 2020 20:37 |
I've broken this up in sections, please excuse the multiquoting.fletcher posted:I'm in the process of setting up my new NAS to migrate from NAS4Free over to FreeNAS. Previously with NAS4Free, I just had my fletch_vdev pool with no datasets, and the /mnt/fletch_vdev was shared via Samba for my Windows machine. Another benefit of datasets is that if you have one for your home movies or your own music, or stuff that's otherwise compressed, you can disable in-line compression on those datasets - but you don't have to, since lz4 has an early-abort feature whereby if compression doesn't reach 17% it'll stop trying. fletcher posted:I was planning on using zfs send/recv with nc to send it over the wire. To facilitate that, on my old NAS I created the datasets and started moving the files around, then I can do the zfs send/recv on each of the datasets. The reason using a buffer is a good idea is that ZFS send will first compute what needs to be sent over the wire (and try to arrange the data sequentially, if possible), and then send it - each of these steps is serialized rather than parallelized, though, so if you don't create a memory buffer (which is what mbuffer exists for, the network I/O is just an added benefit), it can take longer than is strictly necessary. fletcher posted:I had just about completed that part on the old NAS when I noticed it started going very very slow. Sure enough: I've finally got a better solution for local backup now, but the 78000 hours on my servers disks still make me wish I could afford to replace them before they die.
|
|
# ? Jun 18, 2020 05:27 |
D. Ebdrup posted:Depending on how you access your shares, you'll need to be very careful about ACLs. Is the dataset only going to be accessed by Windows, now or in the future? If so, you can set the share type to SMB instead, and sambad will use the winacl and smbcacls commands instead of chown and chmod. On the other hand, it means that you won't be able to use chmod and chown if you're accessing the dataset from the FreeBSD-like CLI or if you suddenly decide you want to use NFSv4 sharing in Windows (which it supports, and at least for me runs better than SMB). Interesting! I didn't know that Windows supported NFSv4. It sounds like Windows doesn't have an official NFSv4 client though, only server. Are you using the client from University of Michigan? I am only planning on accessing these datasets from Windows machines both now and in the future, so I was planning on using the SMB share type on the new NAS. D. Ebdrup posted:Another benefit of datasets is that if you have one for your home movies or your own music, or stuff that's otherwise compressed, you can disable in-line compression on those datasets - but you don't have to, since lz4 has an early-abort feature whereby if compression doesn't reach 17% it'll stop trying. I didn't really consider the compression setting, thinking about my data maybe it makes sense to disable compression on all my datasets. D. Ebdrup posted:I would recommend using mbuffer -O and -I since it does exactly the same as netcat (ie. send data over the wire, unencrypted) but also acts as a buffer. Good to know! I guess one of the advantages with netcat is that it was already available on both machines. I'll see if there's a way get it on my ancient version of NAS4Free. D. Ebdrup posted:That's a big yikes. "scrub repaired 213M in 47h1m with 0 errors" hopefully it makes it through the big transfers! Thanks for the tips D. Edbdrup.
|
|
# ? Jun 18, 2020 08:49 |
|
D. Ebdrup posted:Ever since filesystems started implementing hierarchies of folders in the 70s, there's been very little distinction between them. OK but a folder isn't automatically a new dataset, as far as I can tell, and "alias mkdir to 'zfs create'" is neat idea but not something that's going to occur to most people. Probably not hard to replace a directory hierarchy with a bunch of hived-off datasets after the fact, but still not the obvious thing to do when you're a home fletcher posted:Interesting! I didn't know that Windows supported NFSv4. It sounds like Windows doesn't have an official NFSv4 client though, only server. Are you using the client from University of Michigan? I am only planning on accessing these datasets from Windows machines both now and in the future, so I was planning on using the SMB share type on the new NAS. Could've sworn Explorer became a client after you installed the feature but now I can't find the feature to install since they dumbed down the UI 😑 Munkeymon fucked around with this message at 16:43 on Jun 18, 2020 |
# ? Jun 18, 2020 16:40 |
|
|
# ? Jun 5, 2024 06:41 |
|
Munkeymon posted:OK but a folder isn't automatically a new dataset, as far as I can tell, and "alias mkdir to 'zfs create'" is neat idea but not something that's going to occur to most people. Probably not hard to replace a directory hierarchy with a bunch of hived-off datasets after the fact, but still not the obvious thing to do when you're a home
|
# ? Jun 18, 2020 16:52 |