Jump to content

JorgeB

Moderators
  • Posts

    67,119
  • Joined

  • Last visited

  • Days Won

    703

Everything posted by JorgeB

  1. XFS is more mature and stable than btrfs, it's a good choice if you don't care for snapshots and/or checksums, reiser is dead.
  2. https://forums.unraid.net/topic/77338-xfs-encryption-questions/?do=findComment&comment=715562 With the 2nd option you can backup just one or more shares. For the remote connection search the forum for VPN, not really sure which one is the best/easier to config since I never needed to use one.
  3. It is, usually minimum operating temp is 0C, and even that is too cold and not good for the disks, operating disks at very low temps (<30C) can be as bad as high temps, there's a Google study about it.
  4. If the connection isn't stable best to use rsync since it can resume a transfer. Yes, last subfolder would need to be a subvolume, but it would just need to be created, it looks like a normal folder.
  5. If you scroll down you'll see send/receive, that's what's used to send snapshots from one server to another, locally or remotely, but you need to keep one thing in mind, with Unraid each disk is an independent file system, so you can't for example snapshot an user share that spans more than one disk and send/receive to another server, there are two options: 1 - both source and destination server have the same disk config, same number of disks with the same capacity (can be larger on dest): snapshot each disk on source, use send receive to send the initial snapshot to the equivalent disk on the backup server, then keep using send/receive to send incremental snapshots of each disk, as long as snapshots for all disks have the same name, e.g. backup_20190129, they can be browsed all together as an user share both on source and dest. 2 - source and destination have a different disk config, this is the one I use since I reuse old upgraded disks on my backup servers, so they always have more but smaller disks than source: snapshot each disk on the destination server (you can also keep snapshots on the source server to protect from accidental deletes or ransomware but not needed for this, in fact source can even be using a different filesystem), rsync both servers, as long as snapshots for all disks have the same name, e.g. backup_20190129, they can be browsed all together as an user share.
  6. Snapshots are part of btrfs, no need for anything extra, some info on how to create them here: https://forums.unraid.net/topic/51703-vm-faq/?do=findComment&amp;comment=523800
  7. You can schedule the snapshots at any time and take as many as you like, they don't use any space unless changes are made to the existing files, I only do it at array start time since the backup servers are off except for when I sync them.
  8. Those use a Marvell chipset, so likely related to the Marvell issue.
  9. Yes, I meant speeds, I asked cause in a recent test local speeds using the write test scrip were well below the actual transfer speed over lan, e.g., this is the previously mentioned Crucial MX500: writing 10240000000 bytes to: /mnt/disks/temp2/test.dat 1146062+0 records in 1146061+0 records out 1173566464 bytes (1.2 GB, 1.1 GiB) copied, 5.00033 s, 235 MB/s 2139461+0 records in 2139461+0 records out 2190808064 bytes (2.2 GB, 2.0 GiB) copied, 10.0027 s, 219 MB/s 3360510+0 records in 3360510+0 records out 3441162240 bytes (3.4 GB, 3.2 GiB) copied, 15.009 s, 229 MB/s 4545742+0 records in 4545742+0 records out 4654839808 bytes (4.7 GB, 4.3 GiB) copied, 20.0134 s, 233 MB/s 5625066+0 records in 5625065+0 records out 5760066560 bytes (5.8 GB, 5.4 GiB) copied, 25.0169 s, 230 MB/s 6686880+0 records in 6686880+0 records out 6847365120 bytes (6.8 GB, 6.4 GiB) copied, 30.0352 s, 228 MB/s 7778356+0 records in 7778356+0 records out 7965036544 bytes (8.0 GB, 7.4 GiB) copied, 35.0504 s, 227 MB/s 8863897+0 records in 8863897+0 records out 9076630528 bytes (9.1 GB, 8.5 GiB) copied, 40.0248 s, 227 MB/s 9904846+0 records in 9904846+0 records out 10142562304 bytes (10 GB, 9.4 GiB) copied, 45.0248 s, 225 MB/s 10000000+0 records in 10000000+0 records out 10240000000 bytes (10 GB, 9.5 GiB) copied, 45.4796 s, 225 MB/s write complete, syncing
  10. Depends on how much writes you do, but changing to daily is a good option in any case it won't do any harm. I found the write test sometimes generates lower speeds than an actual transfer, what seeds are you seeing during a transfer? I can for example tell you that a 500GB Crucial MX500 can write at 500MB/s for the first few GB while using SLC cache and then slows down a little but it can still sustain around 400MB/s writes.
  11. A few things to try: - see if there's any difference reading from a disk share vs an user share - toggle Direct IO (Settings -> Global Share settings) - some time ago using an older SMB version could make a big difference, not so much recently but worth a try, for example to limit to SMB 2, add to "Samba extra configuration" on Settings -> SMB: max protocol = SMB2_02
  12. Are you regularly trimming the SSD? Except for that can't think of anything else, except it's not that fast with sustained writes, benchmarks mostly test the small SLC cache, so sometimes can be misleading.
  13. It's not: FWVersion(20.00.00.00) There are known issues with this firmware, you should update to 20.00.07.00, though not likely to fix the CRC errors, if it's not cables/backplane it's likely the controller.
  14. A few things to try: - see if there's any difference reading from a disk share vs an user share - toggle Direct IO (Settings -> Global Share settings) - some time ago using an older SMB version could make a big difference, not so much recently but worth a try, for example to limit to SMB 2, add to "Samba extra configuration" on Settings -> SMB: max protocol = SMB2_02
  15. Can't reproduce this, does the same happen in safe mode?
  16. I believe the btrfs faq phrases it the best: I've been using btrfs only on all my Unraid servers for the last 2 or 3 years, and I love it, but of course I have backups. Yes.
  17. Is that the original WD Blue or the newer WD Blue 3D? Those look like pre-3D speeds, but either way the SSD is the limit, get a faster one.
  18. Turn on backup server, it automatically snapshots all disks at array startup, then I run rsync over ssh between both servers. Go back to previous snapshot, snapshots are read-only and can't be modified/encrypted.
  19. That's not correct, please post the diagnostics: Tools -> Diagnostics, though likely unrelated to this release, so probably best to post in the general support forum.
  20. Yep, it's Marvell: 01:00.0 Non-Volatile memory controller [0108]: Sandisk Corp WD Black NVMe SSD [15b7:5001] Subsystem: Marvell Technology Group Ltd. Device [1b4b:1093]
  21. mlx4 is the Mellanox driver, maybe try without that NIC for a while.
  22. Cache is 99% full, and after emptying some data run a balance since it's also fully allocated, though it might not be after some space is freed: https://lime-technology.com/forums/topic/62230-out-of-space-errors-on-cache-drive/?do=findComment&amp;comment=610551
  23. WD Black NVMe devices do, at least initial models did, we can confirm if you post the diagnostics.
  24. You can use btrfs on the backup server and make snapshots before syncing, that's what I do on all my backup servers.
×
×
  • Create New...