[Fixed] vSphere System Logs are Stored on Non-persistent Storage

The system logs are stored on non-persistent storage

vSphere system logs are a vital component of managing and maintaining VMware vSphere environments. They provide critical information for troubleshooting, performance optimization, security, compliance, capacity planning, change management, and proactive monitoring. By leveraging the insights provided by these logs, you can ensure the stability, efficiency, and security of the virtual infrastructure.

Non-persistent storage refers to a type of storage that does not retain data permanently. In the context of computing environments, such as virtualization or cloud computing, non-persistent storage is used to provide temporary or transient storage for applications and user sessions.

In non-persistent storage, any changes or modifications made to the data or files are not saved permanently. When an application session ends or the system is rebooted, all changes made to the non-persistent storage are discarded, and the storage is restored to its original state.

Pros and cons of storing vSphere system logs on non-persistent storage

Non-persistent storage is a unique approach which offers some benefits, however, also introduces the challenge of preserving critical data like vSphere system logs.

Pros of storing vSphere system logs on non-persistent storage

1. Easy Management: Since non-persistent storage is designed to discard changes, it ensures that logs are consistently reset to their original state at the start of each session. This eliminates the need for manual log cleanup or rotation, streamlining log management processes.

2. Enhancing Security: This can be beneficial in environments where privacy and data protection are critical, as it reduces the risk of unauthorized access to log information that might contain sensitive data.

3. Performance Efficiency: Since changes to logs on non-persistent storage are discarded, there is no accumulation of unnecessary log data. This reduces storage requirements and can lead to faster log retrieval and analysis.

Cons of storing vSphere system logs on non-persistent storage

1. Limiting Historical Analysis: This can pose challenges when troubleshooting issues that span multiple sessions or require a deeper understanding of the system's historical behavior.

2. Loss of Audit Trail: Auditing and compliance requirements often necessitate the retention of logs to demonstrate adherence to security policies, regulatory standards, or internal governance.

3. Limiting Log Analysis: Log analysis tools and processes that rely on historical log data may be constrained when logs are stored on non-persistent storage.

You would better carefully evaluate these pros and cons and consider your specific requirements and regulatory obligations before deciding whether to store vSphere system logs on non-persistent storage.

How to solve vSphere system logs are stored on non-persistent storage

You may get the warning “system logs are stored on non-persistent storage”. This is due to the fact that the host keeps its logs in temporary files that will be deleted after a reboot. Here are the solution about how to suppress the system logs on host are stored on non-persistent storage.

Verify the location of system logs in vSphere client (HTML5)

1. Navigate to the Hosts and Clusters view in the vSphere Client.

2. Select the specific host object from the list in the vSphere Client navigator. Then click Configure tab, then expand System settings.

3. In the System settings, click on Advanced System Settings.

4. Verify that the Syslog.global.logDir point is set to a persistent location.

5. If the Syslog.global.logDir field is empty or points to a scratch partition, make sure that the ScratchConfig.CurrentScratchLocation field indicates a location on persistent storage.

6. If the designated folder for the scratch location is intended to be shared among multiple ESXi hosts, it is advisable to also configure the Syslog.global.logDirUnique field to avoid conflicts over log files.

Note: To log to a datastore, use the format [Datastorename]/foldername for the Syslog.global.logDir entry. To log in to the scratch partition set in the ScratchConfig.CurrentScratchLocation, use a blank format or [ ]/foldername.

Check the location of system logs in vSphere web client

1. Access to the desired host using the vSphere Web Client navigator. Click Manage and then select Settings.

2. In the System section, click Advanced System Settings.

3. Verify that the Syslog.global.logDir point is configured to a location that ensures data persistence.

4. If the Syslog.global.logDir field is empty or points to a scratch partition, ensure that the ScratchConfig.CurrentScratchLocation field indicates a location on persistent storage.

5. If the designated scratch location folder is intended to be shared among multiple ESXi hosts, it is recommended to configure the Syslog.global.logDirUnique field to prevent conflicts over log files.

Confirm the location of system logs in vSphere client (vSphere 6.0 and earlier)

1. In the vSphere Client, select the desired host from the inventory panel. Click Configuration and then choose Advanced Settings under the Software section.

2. Verify that the Syslog.global.logDir point is configured to point to a persistent location. Specify the directory using the format [datastorename] path_to_file, where the path is relative to the datastore. For instance, [datastore1]/systemlogs.

3. If the Syslog.global.logDir field is either empty or explicitly set to a scratch partition, ensure that the ScratchConfig.CurrentScratchLocation field indicates a location on persistent storage.

Note: Reboot the ESXi server to apply the changes made to the Scratch configuration. The Current configuration location should match the Configured location to ensure successful implementation of the changes.

Efficient backup software to ensure data integrity and security

As we have explored the challenges and considerations of storing vSphere system logs on non-persistent storage, it becomes evident that a reliable VMware backup solution is crucial for ensuring the integrity and security of log data. While non-persistent storage offers benefits in terms of simplicity and resource optimization, it also introduces potential risks, such as data loss in the event of storage failures or system reboots.

To mitigate these risks, I would like to introduce a reliable and efficient vSphere backup software - AOMEI Cyber Backup, which enables you to backup multiple VMs either managed by vCenter Server, or on a standalone ESXi host.

It simplifies the backup process and present the steps with intuitive GUI interface. In addition, it offers you the following benefits.

✦ Agentless Backup: Create complete and independent image-level backup for VMware ESXi and Hyper-V VMs.
✦ Flexible vSphere Backup: Batch backup large numbers of VMs managed by vCenter Server, or on a standalone ESXi host.
✦ Automated Execution: Automate backup tasks to run daily, weekly, or monthly and notify by email.
✦ Role Assignment: Allows you to create sub-accounts with limited privileges.

AOMEI Cyber Backup supports both paid and free versions of VMware ESXi 6.5 and later versions. Next, I will show you how to perform vSphere VM backup and restore via AOMEI Cyber Backup. You can click the following button to download the 30-day free trial.

*You can choose to install this VM backup software on either Windows or Linux system.

Steps to perform vSphere backup and restore via AOMEI Cyber Backup

1. Bind Devices: Access to AOMEI Cyber Backup web client, navigate to Source Device >> VMware >> + Add VMware Device to Add vCenter or Standalone ESXi host. And then click … >> Bind Device.

2. Create Backup Task: Navigate to Backup Task >> + Create New Task, and select VMware ESXi Backup as the Backup Type.

3. Specify backup task setting - Task Name, Device, Target, Schedule, and Cleanup as needed.

• Task Name: Change the task name or use the default name with an ordinal.
• Device: Batch select large numbers of VMs managed by vCenter Server for centralized backup.

• Target: Select to back up to a local path, or to a network path.
• Schedule (optional): Perform full, differential, or incremental backup, and automate execution according to the frequency you specified.

• Cleanup (optional): Automatically delete the old backup copies that exceed the retention period you specified.

4. Run Backup: Click Start Backup and select Add the schedule and start backup now, or Add the schedule only.

5. Start Restore: Choose to Restore to original location or Restore to new location. And click Start Restore to restore VM from backup.

Conclusion

In conclusion, by evaluating the pros and cons of storing logs in such an environment, and recognizing how to resolve the problem of vSphere system logs are stored on non-persistent storage, you can make informed decisions regarding log management.

Regardless of where your vSphere system logs are stored, it's crucial to prioritize data safety. Implement robust backup strategies, maintain proper access controls, and regularly review and monitor your vSphere performance. Remember, data is a valuable asset, and taking proactive measures to protect and secure it should be a top priority.