Bottom line: Write down which messages each intended receiver should obtain before saving remote logging settings. Treat a second destination as another configuration to verify, rather than evidence that the complete logging path is automatically redundant.
\nThe TrueNAS system-logging guide allows a syslog server or an array of two servers, each with its own host, transport and TLS certificate settings. It says certificates must be added to TrueNAS before selecting TLS transport. The selected Syslog Level is the minimum priority sent remotely; the system forwards messages at or above that level. The guide says entries are written locally as well as sent to the remote server and provides an Add Syslog Server step for a second destination.
\nThese settings do not establish durable receipt, failover, a particular retry policy or completeness of an investigator’s search. DSE uses this article for the TrueNAS receiver and priority-selection decision. The collector’s retention, access controls and transport validation require their own evidence.
\nThe following steps are DSE recommendations based on the cited source.
\nDSE recommends a receiver worksheet with separate rows for the first and second destination. Record each host and port, transport, certificate reference where applicable and owner. Record the selected Syslog Level once as the reviewed forwarding threshold alongside the endpoint rows. Check the actual saved values rather than assuming the second endpoint repeats the first.
\nDefine proposed test messages on both sides of the selected priority boundary using an approved method for the installed system. Give the test inputs harmless identifiers and retain their intended class and time. Ask the logging owner which messages should appear remotely and which should remain outside the forwarded scope. Do not describe an intentional priority exclusion as a transport failure.
\nReview each receiver’s actual observations independently. If a second receiver is part of the requirement, require evidence for it rather than accepting the first receiver’s search result as coverage for both. Keep any resilience or interruption exercise in a separate approved plan with its own expected behavior; the configuration screen alone should not supply that expectation.
\nReview the proposed receiver names with the team that searches them during incidents. Use the same harmless event identifier in each authorized search, and preserve a missing second-receiver result as a separate finding rather than substituting the first receiver’s screenshot.
\nProposed verification: compare the approved local test observations with the records found at each configured receiver. Record input identifier, priority, time, selected threshold and receiver result. Investigate missing included messages and unexpected excluded messages before changing the threshold merely to make the test appear successful.
\nFor the selected transport, perform the relevant approved connection and trust checks without exposing private keys. Retain the receiver worksheets, redacted configuration and actual search evidence. Have the incident-response owner confirm that the agreed message population can be found. Keep this acceptance separate from a claim about buffering or recovery during a future collector interruption.
\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Write down which messages each intended receiver should obtain before saving remote logging settings. Treat a second destination as another configuration to verify, rather than evidence that the complete logging path is automatically redundant.\nSource fact: what the authority says\nThe TrueNAS system-logging guide allows a syslog server or an array of two servers, each with its own host, transport and TLS certificate settings. It says certificates must be added to TrueNAS before selecting TLS transport. The selected Syslog Level is the minimum priority sent remotely; the system forwards messages at or above that level. The guide says entries are written locally as well as sent to the remote server and provides an Add Syslog Server step for a second destination.\nWhat the source does not establish\nThese settings do not establish durable receipt, failover, a particular retry policy or completeness of an investigator’s search. DSE uses this article for the TrueNAS receiver and priority-selection decision. The collector’s retention, access controls and transport validation require their own evidence.\nApplicability questions\n\nWhich one or two receivers are intended, and who owns each endpoint?\nWhat priority threshold and message classes must the investigation workflow receive?\nWhat transport and certificate reference are selected for each receiver?\nHow will an operator distinguish local observation, remote receipt and downstream search availability?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a receiver worksheet with separate rows for the first and second destination. Record each host and port, transport, certificate reference where applicable and owner. Record the selected Syslog Level once as the reviewed forwarding threshold alongside the endpoint rows. Check the actual saved values rather than assuming the second endpoint repeats the first.\nDefine proposed test messages on both sides of the selected priority boundary using an approved method for the installed system. Give the test inputs harmless identifiers and retain their intended class and time. Ask the logging owner which messages should appear remotely and which should remain outside the forwarded scope. Do not describe an intentional priority exclusion as a transport failure.\nReview each receiver’s actual observations independently. If a second receiver is part of the requirement, require evidence for it rather than accepting the first receiver’s search result as coverage for both. Keep any resilience or interruption exercise in a separate approved plan with its own expected behavior; the configuration screen alone should not supply that expectation.\nReview the proposed receiver names with the team that searches them during incidents. Use the same harmless event identifier in each authorized search, and preserve a missing second-receiver result as a separate finding rather than substituting the first receiver’s screenshot.\nVerification and evidence\nProposed verification: compare the approved local test observations with the records found at each configured receiver. Record input identifier, priority, time, selected threshold and receiver result. Investigate missing included messages and unexpected excluded messages before changing the threshold merely to make the test appear successful.\nFor the selected transport, perform the relevant approved connection and trust checks without exposing private keys. Retain the receiver worksheets, redacted configuration and actual search evidence. Have the incident-response owner confirm that the agreed message population can be found. Keep this acceptance separate from a claim about buffering or recovery during a future collector interruption.\nOfficial references\n\nTrueNAS — Managing System Logging — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Write down which messages each intended receiver should obtain before saving remote logging settings. Treat a second destination as another configuration to verify, rather than evidence that the complete logging path is automatically redundant.\n\n## Source fact: what the authority says\n\nThe [TrueNAS system-logging guide](https://www.truenas.com/docs/scale/25.10/scaletutorials/systemsettings/advanced/managesyslogsscale/) allows a syslog server or an array of two servers, each with its own host, transport and TLS certificate settings. It says certificates must be added to TrueNAS before selecting TLS transport. The selected Syslog Level is the minimum priority sent remotely; the system forwards messages at or above that level. The guide says entries are written locally as well as sent to the remote server and provides an Add Syslog Server step for a second destination.\n\n## What the source does not establish\n\nThese settings do not establish durable receipt, failover, a particular retry policy or completeness of an investigator’s search. DSE uses this article for the TrueNAS receiver and priority-selection decision. The collector’s retention, access controls and transport validation require their own evidence.\n\n## Applicability questions\n\n- Which one or two receivers are intended, and who owns each endpoint?\n\n- What priority threshold and message classes must the investigation workflow receive?\n\n- What transport and certificate reference are selected for each receiver?\n\n- How will an operator distinguish local observation, remote receipt and downstream search availability?\n\n## DSE recommendation: controlled next steps\n\nThe following steps are DSE recommendations based on the cited source.\n\nDSE recommends a receiver worksheet with separate rows for the first and second destination. Record each host and port, transport, certificate reference where applicable and owner. Record the selected Syslog Level once as the reviewed forwarding threshold alongside the endpoint rows. Check the actual saved values rather than assuming the second endpoint repeats the first.\n\nDefine proposed test messages on both sides of the selected priority boundary using an approved method for the installed system. Give the test inputs harmless identifiers and retain their intended class and time. Ask the logging owner which messages should appear remotely and which should remain outside the forwarded scope. Do not describe an intentional priority exclusion as a transport failure.\n\nReview each receiver’s actual observations independently. If a second receiver is part of the requirement, require evidence for it rather than accepting the first receiver’s search result as coverage for both. Keep any resilience or interruption exercise in a separate approved plan with its own expected behavior; the configuration screen alone should not supply that expectation.\n\nReview the proposed receiver names with the team that searches them during incidents. Use the same harmless event identifier in each authorized search, and preserve a missing second-receiver result as a separate finding rather than substituting the first receiver’s screenshot.\n\n## Verification and evidence\n\nProposed verification: compare the approved local test observations with the records found at each configured receiver. Record input identifier, priority, time, selected threshold and receiver result. Investigate missing included messages and unexpected excluded messages before changing the threshold merely to make the test appear successful.\n\nFor the selected transport, perform the relevant approved connection and trust checks without exposing private keys. Retain the receiver worksheets, redacted configuration and actual search evidence. Have the incident-response owner confirm that the agreed message population can be found. Keep this acceptance separate from a claim about buffering or recovery during a future collector interruption.\n\n## Official references\n\n- [TrueNAS — Managing System Logging](https://www.truenas.com/docs/scale/25.10/scaletutorials/systemsettings/advanced/managesyslogsscale/) — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/", "url": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-28" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Review each TrueNAS syslog destination and the forwarding threshold", "item": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/#article", "identifier": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/", "url": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/", "headline": "Review each TrueNAS syslog destination and the forwarding threshold", "description": "TrueNAS documents two syslog destinations with individual transport and certificate settings plus a minimum forwarded priority…", "abstract": "TrueNAS documents two syslog destinations with individual transport and certificate settings plus a minimum forwarded priority; verify each receiver’s intended scope.", "articleBody": "Bottom line: Write down which messages each intended receiver should obtain before saving remote logging settings. Treat a second destination as another configuration to verify, rather than evidence that the complete logging path is automatically redundant.\nSource fact: what the authority says\nThe TrueNAS system-logging guide allows a syslog server or an array of two servers, each with its own host, transport and TLS certificate settings. It says certificates must be added to TrueNAS before selecting TLS transport. The selected Syslog Level is the minimum priority sent remotely; the system forwards messages at or above that level. The guide says entries are written locally as well as sent to the remote server and provides an Add Syslog Server step for a second destination.\nWhat the source does not establish\nThese settings do not establish durable receipt, failover, a particular retry policy or completeness of an investigator’s search. DSE uses this article for the TrueNAS receiver and priority-selection decision. The collector’s retention, access controls and transport validation require their own evidence.\nApplicability questions\n\nWhich one or two receivers are intended, and who owns each endpoint?\nWhat priority threshold and message classes must the investigation workflow receive?\nWhat transport and certificate reference are selected for each receiver?\nHow will an operator distinguish local observation, remote receipt and downstream search availability?\n\nDSE recommendation: controlled next steps\nThe following steps are DSE recommendations based on the cited source.\nDSE recommends a receiver worksheet with separate rows for the first and second destination. Record each host and port, transport, certificate reference where applicable and owner. Record the selected Syslog Level once as the reviewed forwarding threshold alongside the endpoint rows. Check the actual saved values rather than assuming the second endpoint repeats the first.\nDefine proposed test messages on both sides of the selected priority boundary using an approved method for the installed system. Give the test inputs harmless identifiers and retain their intended class and time. Ask the logging owner which messages should appear remotely and which should remain outside the forwarded scope. Do not describe an intentional priority exclusion as a transport failure.\nReview each receiver’s actual observations independently. If a second receiver is part of the requirement, require evidence for it rather than accepting the first receiver’s search result as coverage for both. Keep any resilience or interruption exercise in a separate approved plan with its own expected behavior; the configuration screen alone should not supply that expectation.\nReview the proposed receiver names with the team that searches them during incidents. Use the same harmless event identifier in each authorized search, and preserve a missing second-receiver result as a separate finding rather than substituting the first receiver’s screenshot.\nVerification and evidence\nProposed verification: compare the approved local test observations with the records found at each configured receiver. Record input identifier, priority, time, selected threshold and receiver result. Investigate missing included messages and unexpected excluded messages before changing the threshold merely to make the test appear successful.\nFor the selected transport, perform the relevant approved connection and trust checks without exposing private keys. Retain the receiver worksheets, redacted configuration and actual search evidence. Have the incident-response owner confirm that the agreed message population can be found. Keep this acceptance separate from a claim about buffering or recovery during a future collector interruption.\nOfficial references\n\nTrueNAS — Managing System Logging — official product documentation; confirm the installed release and configuration.\n\nSource review completed October 28, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T00:10:00+00:00", "dateModified": "2026-10-29T00:10:35+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/review-each-truenas-syslog-destination-and-the-forwarding-threshold/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Review each TrueNAS syslog destination and the forwarding threshold" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 584, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "TrueNAS — Managing System Logging", "url": "https://www.truenas.com/docs/scale/25.10/scaletutorials/systemsettings/advanced/managesyslogsscale/" } } ] } }