Several beginners question

[dffvb]

Hi there,

I have multiple beginner questions, I dont know whether all in one thread or several threads are prefered?

First question: I have an old Samsung 950 PRO 512 GB – using it as system drive feels a bit wasted, so I was wondering if it is okay to partition it and install to a part thereof? Raid owl made a video on it, so I would follow his approach… or are the road blockas against this?

Second question: BackUp of TrueNAS itself, I know there is the backup option of the conf in the settings, and there are snapshots for pools / datasets. Also too via "Data Protection" I can copy / sync Datasets to external storage. I am wondering whether something like Veeam BackUp Agent for Linux would be of any help? And also backing up VMs, I just set snapshots to be taken on the Dataset regularly right?

Third question: Information gathering – since TrueNAS Scale is sort of new, is there a good overview of best practices etc. where one can pickup information? (other than official documentation) ?

Fourth question: Multi Protocols for the same share (i.e. SMB, WebDAV and Minio) - what are the risks here? Is it bad practice? If yes, why?

Fifth question: Disk settings for SSD only pools - 5 minutes stand by and Advanced Power Management Level 64 okay? Energy Saving features for SSDs anything to pay attention to?

Sixth question: Encryption – whats the best way to encrypt the data, without losing to much performance, and not having to enter the passwords after each reboot? Chose Encryption right at the start when adding a new pool? Or better via SED Password?

Seventh question: Sync settings under "Pool options" - if I add a SLOG device, and have Sync disabled, what happens? Generally where can I read about sync? In standard the client software determines whether it wants to knwo if a sync has been completed, where do I know which client software requests what? In which cases would I want to discabel sync, if I risk losing 5 senonds of data? Where can i read about it?

Many thanks in advance

 

[NugentS]

1. Here be dragons. Youy can do this - but on your own head be it
2. Snapshots & replication are your goto for VMs etc. You can always backup via SMB if you need to or rsync. No idea about the Veeam agent
3. Same as TN Core
4. I believe its bad practise to have write access via multiple protocols to the same dataset, in particular NFS and SMB. I have one share that is acessible via NFS and SMB, but the NFS share is RO. YMMV, just be careful
5. I wouldn't botherwith SSD energy savings pesonally.
6. Depends on why you want to encrypt. I encrypt one dataset so that if someone steals the server they won't get access to that dataset
7. SLOG is basically NFS and iSCSI. Setting sync = disabled will be as fast as the pool can go, but at risk to the data in the event of an unforseen power event or kernel panic. Do not bother with a SLOG if you use sync=disabled. You can read about it on this forum - look in resources

 

[sretalla]

would I want to discabel sync, if I risk losing 5 senonds of data?

Five seconds of data might be something you consider trivial to lose, but if that 5 seconds happens to be some critical (and unfinished) operations to a database or filesystem metadata, you could lose a whole application or pool... risk is yours to take.

 

[dffvb]

@sretalla Yes exactly - so lets ask the question the other way round: In which scenarios would I disable it?

 

[NugentS]

When you really don't care about the data / have up to date backups.

 

[appliance]

1) relates to 6) - imo i'd not waste a SSD drive, rather boot from a flash drive, and utilize SSD for System Dataset, Apps, Downloads, and Cameras. If the boot drive will be SSD itself, the advantage of SED locking will be instantly gone and massive capacity and the speed advantage will be lost for a few gigs of data.

3) the web guide, which is unfortunately less detailed than the famous user manuals before. More googling required nowadays.

5) APM 127 for standby, APM 254 for no standby (max performance each), but safest to DISABLE. Spindow time can be very low for SSD, rather higher for spinning drives. If disk hibernation is required, SMART service "Power Mode" should be set to Standby, otherwise smartd agent will wake up the drives every 30min despite not performing a test. Because this is a tricky area, i always monitor the standby with

Code:

hdparm -C /dev/sd? >> idle.log

for the first days to see 1) the settings work 2) apps are not waking it up to a level where standby doesn't make sense.

6) SED for the system (non boot) drive, plus keyfile encryption there. Password encryption for the other (data) drives, but if you want automatic unlock, there will be a chain of hashes to grab. Already SED implementation is questionable, your old SSD password is probably readable.

7) sync can be disabled anywhere it feels good like download or surveillance dataset. Doesn't feel right for apps and databases. Anyways, when zfs breaks, sync or copyonwrite or UPS or ECC won't save a day. So why not lose some files which zfs will repair (in theory).

 

[dffvb]

@appliance Thanks a lot for this profound and detailed answer!

 

[danb35]

I was wondering if it is okay to partition it and install to a part thereof?

I have to waste an entire drive just for booting?

With the advent of TrueNAS Scale, we seem to be getting a large number of people from the Linux community who are not quite grasping what TrueNAS is. TrueNAS is not a "Linux distro" and it is not designed to try to meet your arbitrarily spec'd...

www.truenas.com

I am wondering whether something like Veeam BackUp Agent for Linux would be of any help?

No, because SCALE (just like CORE) does not support the installation of random software on the base OS. But beyond that, the question would be what you'd want it to accomplish that you can't do in some other way.

whats the best way to encrypt the data, without losing to much performance, and not having to enter the passwords after each reboot?

Against what sort of threat are you trying to protect here?

where can I read about sync?

Google will tell you a lot. With sync writes, data must be committed to permanent storage before the application is told the write operation is successful. With async, they're typically cached in RAM and flushed to disk at some later time--but if power's lost or something else catastrophic happens first, the data is lost. An inconvenience with most files, potentially catastrophic for databases and disk images--though not generally a problem for the filesystem itself; ZFS's copy-on-write nature makes it quite resilient to damage from power outages and the like (and any vulnerability is independent of sync/async). So why use async at all? Because sync is slow. Really slow. SLOG improves it, but it's still considerably slower than async.