Last edited: Aug 17, Ericloewe said:. The easiest method is to do it according to the day of the month. I think FreeNAS 10 will be a lot more standardized. The current GUI and middleware are a somewhat rushed product that's had stuff tacked on and patched up. It's a somewhat messy solution that is being fixed at the moment. Joined Feb 11, Messages Good luck and happy storing!
Joined Mar 25, Messages 19, I'm not sure where you "see" that. I don't even know what you are talking about when you say "Power Mode". Can you clarify where this setting is you are talking about? The APM I guess UncleFester Member. Joined Feb 8, Messages Thanks for the guide cyberjock that was very useful to me. Marcet Member. Joined May 31, Messages Useful guide, thanks y I'm wondering how long a scrub can last. How can I figure it out before running it? Joined Oct 15, Messages 3, Marcet said:.
DrKK said:. So if you have 3 TiB of data in a pool, then scrubbing the pool is going to run about 4 hours. More or less. So scrub can run for days on my 42 TiB system if it's full up to 3 days. How did that affect performance? Scrubbing is done as non-intrusively as possible. Performance is impacted if you attempt to use the pool during a scrub, but there's more impact against the scrub itself than against the normal user usage.
I think most people don't even realize a scrub is going on. Scharbag Senior Member. Joined Feb 1, Messages When snapshots are automatically created on the source computer, they are replicated to the destination computer. First-time replication tasks can take a long time to complete as the entire snapshot must be copied to the destination system. Replicated data is not visible on the receiving system until the replication task completes. Later replications only send the changes to the destination system.
Interrupting a running replication requires the replication task to restart from the beginning. The target dataset on the receiving system is automatically created in read-only mode to protect the data. To mount or browse the data on the receiving system, create a clone of the snapshot and use the clone. See Snapshots for more information on creating clones. Alpha is the source computer with the data to be replicated. It is at IP address A pool named alphapool has already been created, and a dataset named alphadata has been created on that pool.
This dataset contains the files which will be snapshotted and replicated onto Beta. This new dataset has been created for this example, but a new dataset is not required. Most users will already have datasets containing the data they wish to replicate.
Snapshots are automatically deleted after their chosen lifetime of two weeks expires. Beta is the destination computer where the replicated data will be copied. A pool named betapool has already been created. Snapshots are transferred with SSH. To allow incoming connections, this service is enabled on Beta. The service is not required for outgoing connections, and so does not need to be enabled on Alpha.
The Setup mode dropdown is set to Semi-Automatic as shown in Figure 7. A hostname can be entered here if local DNS resolves for that hostname. The Remote Auth Token field expects a special token from the Beta computer.
A dialog showing the temporary authorization token is shown as in Figure 7. On the Alpha system, paste the copied temporary authorization token string into the Remote Auth Token field as shown in Figure 7. Finally, click SAVE to create the replication task. After each periodic snapshot is created, a replication task will copy it to the destination system.
See Limiting Replication Times for information about restricting when replication is allowed to run. The temporary authorization token is only valid for a few minutes. If a Token is invalid message is shown, get a new temporary authorization token from the destination system, clear the Remote Auth Token field, and paste in the new one. A dedicated user can be used for replications rather than the root user.
SSH key authentication is used to allow the user to log in remotely without a password. In this example, the periodic snapshot task has not been created yet. Leave the other fields at their default values, but note the User ID number. Click SAVE to create the user.
On Beta , the same dedicated user must be created as was created on the sending computer. Leave the other fields at their default values. A dataset with the same name as the original must be created on the destination computer, Beta.
The replication user must be given permissions to the destination dataset. On Beta , open a Shell and enter this command:.
The destination dataset must also be set to read-only. Enter this command in the Shell :. The replication user must also be able to mount datasets. Enter vfs. Click SAVE. Back on Alpha , create a periodic snapshot of the source dataset. The IP address of Beta is entered in the Remote hostname field. Set the Dedicated User Enabled option.
Choose repluser in the Dedicated User drop-down. Additional replications can use the same dedicated user that has already been set up. The permissions and read only settings made through the Shell must be set on each new destination dataset. Other operating systems can receive the replication if they support SSH, ZFS, and the same features that are in use on the source system. A public encryption key must be copied from Alpha to Beta to allow a secure connection without a password prompt.
This produces the window shown in Figure 7. Use the mouse to highlight the key data shown in the window, then copy it. The destination pool is betapool. The alphadata dataset and snapshots are replicated there. The replication task runs after a new periodic snapshot is created. The periodic snapshot and any new manual snapshots of the same dataset are replicated onto the destination computer.
When multiple replications have been created, replication tasks run serially, one after another. Completion time depends on the number and size of snapshots and the bandwidth available between the source and destination computers. The first time a replication runs, it must duplicate data structures from the source to the destination computer.
This can take much longer to complete than subsequent replications, which only send differences in data. Snapshots record incremental changes in data. If the receiving system does not have at least one snapshot that can be used as a basis for the incremental changes in the snapshots from the sending system, there is no way to identify only the data that has changed.
In this situation, the snapshots in the receiving system target dataset are removed so a complete initial copy of the new replicated data can be created. Status shows the current status of each replication task.
The display is updated periodically, always showing the latest status. The default Encryption Cipher Standard setting provides good security. Fast is less secure than Standard but can give reasonable transfer rates for devices with limited cryptographic speed.
For networks where the entire path between source and destination computers is trusted, the Disabled option can be chosen to send replicated data without encryption. The Begin and End times in a replication task make it possible to restrict when replication is allowed. These times can be set to only allow replication after business hours, or at other times when disk or network activity will not slow down other operations like snapshots or Scrub Tasks.
The default settings allow replication to occur at any time. These times control when replication task are allowed to start, but will not stop a replication task that is already running.
Once a replication task has begun, it will run until finished. Replication depends on SSH, disks, network, compression, and encryption to work.
A failure or misconfiguration of any of these can prevent successful replication. SSH must be able to connect from the source system to the destination system with an encryption key. This is tested from Shell by making an SSH connection from the source system to the destination system. From the previous example, this is a connection from Alpha to Beta at Start the Shell on the source machine Alpha , then enter this command:.
Verify that this is the correct destination computer from the preceding information on the screen and type yes. At this point, an SSH shell connection is open to the destination system, Beta.
If a password is requested, SSH authentication is not working. See Figure 7. Matching compression and decompression programs must be available on both the source and destination computers. An easy way to diagnose the problem is to set Replication Stream Compression to Off.
On the source computer, Alpha , open a Shell and manually send a single snapshot to the destination computer, Beta. The snapshot used in this example is named auto A symbol separates the name of the dataset from the name of the snapshot in the command.
If a snapshot of that name already exists on the destination computer, the system will refuse to overwrite it with the new snapshot. The existing snapshot on the destination computer can be deleted by opening a Shell on Beta and running this command:. Then send the snapshot manually again.
Resilvering, or the process of copying data to a replacement disk, is best completed as quickly as possible. Increasing the priority of resilvers can help them to complete more quickly. A scrub is the process of ZFS scanning through the data on a pool.
Scrubs help to identify data integrity problems, detect silent data corruptions caused by transient hardware issues, and provide early alerts of impending disk failures. It is recommneded that each pool is scrubbed at least once a month. Bit errors in critical data can be detected by ZFS, but only when that data is read. Scheduled scrubs can find bit errors in rarely-read data.
The amount of time needed for a scrub is proportional to the quantity of data on the pool. Typical scrubs take several hours or longer. Schedule scrubs for evenings or weekends to minimize impact to users. Make certain that scrubs and other disk-intensive activity like S. Tests are scheduled to run on different days to avoid disk contention and extreme performance impacts. Scrubs only check used disk space.
To check unused disk space, schedule S. Tests of Type Long Self-Test to run once or twice a month. When a pool is created, a scrub is automatically scheduled. Scrub tasks are run if and only if the threshhold is met or exceeded and the task is scheduled to run on the date marked. Review the default selections and, if necessary, modify them to meet the needs of the environment.
Note that the Threshold days field is used to prevent scrubs from running too often, and overrides the schedule chosen in the other fields. Also, if a pool is locked or unmounted when a scrub is scheduled to occur, it will not be scrubbed.
Scheduled scrubs can be deleted with the Delete button, but this is not recommended. Scrubs can provide an early indication of disk issues before a disk failure. If a scrub is too intensive for the hardware, consider temporarily deselecting the Enabled button for the scrub until the hardware can be upgraded.
Files or directories can be synchronized to remote cloud storage providers with the Cloud Sync Tasks feature. This Cloud Sync task might go to a third party commercial vendor not directly affiliated with iXsystems.
Cloud Credentials must be defined before a cloud sync is created. One set of credentials can be used for more than one cloud sync. For example, a single set of credentials for Amazon S3 can be used for separate cloud syncs that push different sets of files or directories.
A cloud storage area must also exist. With Amazon S3, these are called buckets. The bucket must be created before a sync task can be created. The time selected is when the Cloud Sync task is allowed to begin. The cloud sync runs until finished, even after the time selected. An example is shown in Figure 7. Click either symbol to open the Logs window. This window displays logs related to the task that ran.
They can take a few minutes to a few days depending on the size of your pool, the performance of your pool, your pool's data storage history, the performance of your system as a whole, and the workload place on your pool during the scrub.
SMART tests are internal drive tests. There is no 'criteria' for what is or isn't done on a particular test. No doubt each manufacturer has their own specifications for what a "short test" and a "long test" entails. Generally, short tests take less than 5 minutes and long tests take hours. Long test usually read an entire platter to check for errors and short tests do a very simple and quick test.
It doesn't end well. SMART tests are non-destructive. So you can run them as often as you want. But, you can only run one test at a time per disk duh? SMART test results do not return a final result. So no email means everything is good. Your average disk will store the last 20 or so test results. So if you do tests at a very high frequency and one test fails it may be removed from the log before you can even examine it closely.
You can blindly steal my schedule or come up with your own. Since this is for a home server and I'm the only user I don't worry about any performance penalty since my pool performs more than adequately even during a scrub. Scrubs are pretty hard on disks. So scheduling them at a frequency that makes you comfortable with your pool is important. One does tests, the other only monitors for the drive to find errors through regular use.
If you are running SSDs, these tests are almost pointless. Do them if you want, but they're not really functioning in the capacity that you'd expect. Both short and long tests typically take seconds to complete for most brands of SSD.
So it's obvious that a long test doesn't actually read every memory cell looking for errors. Theshold is set to 10 days. For example, my scrubs and long test are schedule for 4am. So if I do 3am for short test I could theoretically do one every single day and not have any conflict in the schedule since the test takes 2 minutes.
If you look at my schedule, I never schedule anything on or after the 28th. This is because every month has a different number of days. If you try to schedule things on those days they will be skipped some months.
So instead of trying to deal with it I simply don't schedule anything then. Yes, this means that between the 26th of one month and the first of the next month I don't really do any tests. But to be frank, if you are expecting things to go horribly wrong because you didn't do a test for 5 days, you've got bigger problems and should reconsider your design. There is no right or wrong schedule. If you want to do scrubs every single day you can. It's a bit excessive in my opinion.
0コメント