Can drives on encrypted zpools ever be "replaced"?

Status
Not open for further replies.

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
I've been too busy (read: lazy) to actually look, but either way it would be relevant to the recent comments. I'm a bit of an old-timer and I don't necessarily appreciate change just for the sake of change, and things like that stick out.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Ok, I've replaced another disk and followed this guide to fix it.

  • These steps are for FreeNAS 8.3.1-p2 only. I didn't verify these steps work on any other version of FreeNAS. You are welcome to try but you are on your own if things go ugly(aka... keep backups!).
  • You must be able to use the key+passphrase to mount the encrypted zpool since the recovery key will not be fully functional during this procedure. You should always be using the key+passphrase for this guide except at the very end when I specifically say to use the recovery key.
  • As always.. you should have backups! Yes, I had to say it twice.
  • I am not responsible if you mess this up so badly you lose your data. This worked for me and I make no guarantees that it will work for you.
  • You will get a lot of "An Error Occured" messages in the GUI while we are doing all of this. Based on the other posts in this thread they can be safely ignored. If you are concerned you can look at the footer messages to see if it is anything to worry about.
  • The following steps won't be performed all at once since the resilvering process can be quite long. I recommend you print out these instructions so you can check them off as you do them. Skipping steps can cause very undesirable effects.

Here's step by step for those that aren't familiar with this stuff and confused:

Here's the steps I did that are basically from the manual, but in my own words with a little emphasis on dealing with the encrypted zpool(This is similar to section 6.3.11 of the FreeNAS manual).

1. Backup your FreeNAS config file. ( System -> Settings -> "Save Config" )

2. Mount the encrypted zpool if it is not mounted already.

3. Identify the disk you wish to replace. Using any combination of device designation(for example: /dev/ada1), the gptid (for example: gptid/6fbb91d5-4a95-11e2-bca4-0015171496ae), the disk serial number(depends on your hard drive model), and the label printed on the hard drive you can determine for certainty which disk is the one to replace. For verification purposes you should write down the serial number of the disk to be replaced to ensure you aren't offlining one disk from the array and then physically removing a different disk. Your data could depend on you verifying the correct disk is removed. All of the information above can be matched to other data using the commands:

zpool status (lists gptids used by the zpool)

smartctl -a /dev/adaXX (matches device name to disk serial number) This line may have different parameters if you are using any kind of RAID controller. Consult the manpage for smartctl for assistance.

gpart show -r (matches gptid to /dev/adaXX)

4. In the FreeNAS GUI click on Storage -> Volumes -> View Volumes. Click on the "Volume Status" button for the applicable zpool that will have a disk replaced. Click "Offline" next to the partition that is part of the disk to be replaced. For example, if you are removing da1 you should look for something like da1p2(this stands for da1 partition 2).

5. If you can hot-swap your drives now is the time swap disks. I don't trust hot-swap in FreeBSD so I always shutdown my server. By shutting down the server this also lets me ensure I'm not physically removing a different disk thereby removing another disk from my zpool. In some cases removing the wrong disk with the system online can result in permanent dataloss. Verify that the serial number of the disk you removed matches the serial number you wrote down in step 2.

6. Install your new disk. Power on the system.

7. From the FreeNAS GUI mount your encrypted zpool. ( Storage -> Volumes -> View Volumes )

8. In the FreeNAS GUI click on Storage -> Volumes -> View Volumes. Click on the "Volume Status" button for the applicable zpool. Click the "Replace" button next to the disk that has been removed. Note that it will not give a device and partition. It will be easy to spot because it should be the only disk that doesn't have an "Edit", "Replace" and "Offline" button on its row. In the window that pops up choose the new disk you wish to use and click "Replace Disk".

Resilvering will automatically begin. Resilvering can take anywhere from a few minutes to many days depending on the speed and amount of data in your zpool. You can monitor the resilvering process with the command "zpool status | grep scan". When the resilvering process is complete continue with this guide.

9. In the FreeNAS GUI click on Storage -> Volumes -> View Volumes. Click on the "Volume Status" button for the applicable zpool. Click the "Detach" button for the old disk to complete the disk replacement procedure.

NOTE: All steps after this note are not part of the manual but should repair your encrypted zpool's FreeNAS database information to allow for proper rekeying. This will delete the extra gptid from the FreeNAS database preventing further errors and allowing you to successfully rekey the zpool.

10. Save a list of your gptids for your zpool by using the command zpool status (yourzpoolname) > /mnt/yourzpoolname/somewherethatisshared/gpt.txt. Then copy the text file to your desktop or print it out. Alternately you can choose to write down the gptids on a sheet of paper by typing the command zpool status. Make sure that if you have a large number of disks that you scroll up to see them all.

*** Remember that you are directly editing the FreeNAS configuration file and can cause serious damage if you have any typos. ***

11. I rebooted my server at this point and left the encrypted zpool unmounted in case there is any inconsistencies within FreeNAS while we make our changes. You can choose not to reboot at your own risk. SSH into your box and run the commands as shown. The bold is what I typed:

Code:
# sqlite3 /data/freenas-v1.db
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * from storage_encrypteddisk;
2|2|24|gptid/c1560e68-b86a-11e2-9cfb-0015171496ae
3|2|30|gptid/c1b125e6-b86a-11e2-9cfb-0015171496ae
4|2|31|gptid/c20a0232-b86a-11e2-9cfb-0015171496ae
5|2|33|gptid/c25ef2da-b86a-11e2-9cfb-0015171496ae
6|2|32|gptid/c2b79c49-b86a-11e2-9cfb-0015171496ae
8|2|24|gptid/991f4916-ba6f-11e2-9ed2-0015171496ae
9|2|24|gptid/7b7cf9d9-cda0-11e2-aac8-0015171496ae
sqlite>.quit
# zpool status
  pool: encryptedzpool
 state: ONLINE
  scan: resilvered 0.45GB in 1m with 0 errors on Wed Jun  5 13:39:04 2013
config:

        NAME                                                STATE     READ WRITE CKSUM
        encryptedzpool                                      ONLINE       0     0     0
          raidz2-0                                          ONLINE       0     0     0
            gptid/7b7cf9d9-cda0-11e2-aac8-0015171496ae.eli  ONLINE       0     0     0
            gptid/c1560e68-b86a-11e2-9cfb-0015171496ae.eli  ONLINE       0     0     0
            gptid/c1b125e6-b86a-11e2-9cfb-0015171496ae.eli  ONLINE       0     0     0
            gptid/c20a0232-b86a-11e2-9cfb-0015171496ae.eli  ONLINE       0     0     0
            gptid/c25ef2da-b86a-11e2-9cfb-0015171496ae.eli  ONLINE       0     0     0
            gptid/c2b79c49-b86a-11e2-9cfb-0015171496ae.eli  ONLINE       0     0     0

errors: No known data errors


12. Now to determine what entry in the FreeNAS databse shouldn't be there. If you look at the sql database there are 7 entries while the zpool status lists only 6. The extra entry in the database shouldn't be there. In my case, the extra entry is this line:

Code:
8|2|24|gptid/991f4916-ba6f-11e2-9ed2-0015171496ae


Notice that the line id(the first number) is 8. That's the line we are going to delete.

13. Verify that your encrypted zpool is not mounted. I don't think there is any risk to doing this with the zpool mounted, but its better to be safe than sorry. If it is mounted reboot the server.

14. Run the commands as I demonstrate below, but use your line number:

Code:
# sqlite3 /data/freenas-v1.db
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * from storage_encrypteddisk;
2|2|24|gptid/c1560e68-b86a-11e2-9cfb-0015171496ae
3|2|30|gptid/c1b125e6-b86a-11e2-9cfb-0015171496ae
4|2|31|gptid/c20a0232-b86a-11e2-9cfb-0015171496ae
5|2|33|gptid/c25ef2da-b86a-11e2-9cfb-0015171496ae
6|2|32|gptid/c2b79c49-b86a-11e2-9cfb-0015171496ae
8|2|24|gptid/991f4916-ba6f-11e2-9ed2-0015171496ae
9|2|24|gptid/7b7cf9d9-cda0-11e2-aac8-0015171496ae
sqlite> delete from storage_encrypteddisk where id=8;
sqlite> select * from storage_encrypteddisk;
2|2|24|gptid/c1560e68-b86a-11e2-9cfb-0015171496ae
3|2|30|gptid/c1b125e6-b86a-11e2-9cfb-0015171496ae
4|2|31|gptid/c20a0232-b86a-11e2-9cfb-0015171496ae
5|2|33|gptid/c25ef2da-b86a-11e2-9cfb-0015171496ae
6|2|32|gptid/c2b79c49-b86a-11e2-9cfb-0015171496ae
9|2|24|gptid/7b7cf9d9-cda0-11e2-aac8-0015171496ae
sqlite> .quit


15. Reboot the server again from the GUI or from the command line with shutdown -r now.

16. When the server has booted back up mount your encrypted zpool again. Verify that your zpool is showing as HEALTHY. If it is then all of the drives were properly decrypted. If the zpool is not showing as healthy stop and do not continue.

17. After the zpool is mounted click the "Add Recovery Key" button. A file named "geli_recovery.key" should be available to download.

At this point both your recovery key and the key+passphrase method should again allow your zpool to mount. I recommend you verify that both function and then store them in a safe place. Remember that the old recovery key will no longer work and if you keep it in a secure second location then you will need to update that location also.

18. To verify that the recovery key works you simply need to reboot and mount the encrypted zpool again using the recovery key.

19. To verify the key+passphrase work simply reboot again and mount the encrypted zpool with your key+passphrase. If the zpool status is HEALTHY then everything is working.
 

panz

Guru
Joined
May 24, 2013
Messages
556
Maybe I'm posting a stupid question, but how does ZFS v33 (or v34?) deal with the procedure of replacing a failed HD in an encrypted pool? Different encryption scheme?
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
Unknown. ZFS v33 and v34 aren't part of FreeBSD code and (as far as I know) not part of OpenIndiana either. I believe the newest version of ZFS that is open source is v28(as confirmed by wikipedia)

I will tell you that the ZFS v30 encryption is not even remotely similar to how FreeNAS' geli encryption works. The two are just not compatible at all. If you have an encrypted ZFS pool on FreeNAS the only way to access it is through FreeNAS and through FreeBSD(and possibly other OSes that support ZFS and have geli that is compatible with FreeBSD's version) if you manually mount the drives from the command line via geli. There is no "upgrade" path from FreeNAS' encryption to ZFS' v30 and won't be because of how the encryption is peformed.
 

panz

Guru
Joined
May 24, 2013
Messages
556
I was asking that, because this article instilled a doubt in me, where Aaron says "This will mount the encrypted filesystem “on top” of the ZFS filesystem, allowing you to keep all the COW and error correcting goodness, while keeping your data 100% safe"

http://pthree.org/2012/08/21/encrypted-zfs-filesystems-on-linux/

As I understand, in FreeNAS GELI is sitting below ZFS, so I'm concerned about ZFS being able to do all those good things to ensure data protection. :rolleyes:
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
It works either way. What FreeNAS is doing is similar to what is done by the drive itself if it supports encryption and you give it a password ... a feature most people have never used.
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
This thread is getting off topic. Please start a new thread if you wish to discuss the difference between ZFS' encryption versus the encryption FreeNAS uses.
 

titan_rw

Guru
Joined
Sep 1, 2012
Messages
586
Actually, running encryption on top of zfs breaks, or disabled more features than running it below zfs, as freenas does.

If encryption is after zfs, as it is in that article, compression and dedupe is useless. If you write two identical files, the encryption will take place first, and hand the encrypted blocks off to zfs. Since they're encrypted, the blocks will be totally different, even though the input was the same. So no dedupe will occur. The same thing with compression. If you encrypt a blocks of zeros, you'll get random contents back to hand to zfs. No compression can occur because the data zfs gets is un-compressible.

With encryption at a lower level than zfs, as freenas does, zfs gets the 'plaintext' blocks. So two identical blocks are still identical to zfs. And two compressible blocks are still compressible. Once zfs has 'done it's thing', it hands the blocks off to the encryption layer (geli in freenas). The block is then encrypted and put on disk. This in no way breaks CoW, or zfs's self correcting / self healing. It just adds the overhead of encrypting blocks before storing them on disk.

The only advantage of doing encryption after zfs, as in the article above, is that it could be done on a per dataset basis. You could choose which datasets get encrypted, possibly with different passwords each.

I had previously thought of the possibility to encrypt iscsi extents while leaving the main pool unencrypted. You create a zvol, but then geli it before exporting via iscsi. This would let you have different passwords for each iscsi share, and not force you to encrypt the entire pool. Of course such a config is not supported by freenas. And you'd be limited to single thread encryption performance for each zvol.
 

John Doe

Guru
Joined
Aug 16, 2011
Messages
635
Hi!

I am still having same issue ( the sql table has just an extra column on right filled with "1") on 9.2.1.3.
After replacing ada1 I was getting an error and could not rekey as asked.
I fixed fine using instructions here. (now sql rows are not anymore 1 2 3 4 5 6 7, but 1 2 4 5 6 7, not reordered: hope not bringing problems in the future).

I am wondring why this bug is still there! I was on 8 and upgraded. I tried to do the same upgrade path on a vm but only my productin server had that bug.
Moreover I suppose, by reading how geli works, that only RECOVERY KEY shall not work anymore but MAIN KEY should not be rekeyed if password is provided or no password is set. Instructions are not saying that.

Shall I fill a bug or I am the only one?

Thanks.

Alessandro
 

John Doe

Guru
Joined
Aug 16, 2011
Messages
635
Ciao Panz!

Because of that post I was asking myself why I need rekeying MAIN KEY after replace. GUI asks me passphrase so I am not expecting other than rekeying recovery key which is not inside the usb key.

More important: WHY AM I HAVING THAT ISSUE ON 9.2.1.3?

TNX
Alex
 

panz

Guru
Joined
May 24, 2013
Messages
556
You have to re-key your pool because the master key (the encryption key) would be different for the new disk if you are not going to do the re-key. The passphrase only "protects" the key. Recovery key is the key in the second "slot" of the GELI keyring and it's like a keyfile.
 

John Doe

Guru
Joined
Aug 16, 2011
Messages
635
Ciao!
I understand what you mean but I am asking why passphrase is asked during replace! If key 0 is inside the /data/geli dir and the passphrase is provided the middleware has every information to create the key for the new hdd!
ONLY RECOVERY KEY (key 1) should be reissued. Right?

Any ideas??
 

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
The middleware discards the password after mounting the pool for security reasons. To decrypt the pool you need either the recovery key or the password and its associated key. If the password and key were stored on the server itself (either on the media, RAM, or a combination of both) then anyone that compromises your server, in theory, could have access to the key and password (or recovery key) and could therefore decrypt your pools in the future as the keys are compromised. So for security reasons they aren't stored together.

Even the /data/geli key is only stored there until you create your first set of recovery keys and password/keys. This is because we were having problems with people not creating keys and throwing data on the pools and weeks/months later they reboot to find that they are permanently locked out of their data forever because they had no keys made.
 

John Doe

Guru
Joined
Aug 16, 2011
Messages
635
Ciao Cj,

I can still see the key associated with password (main key) in my /data/geli. I suppose that when I reboot the key is taken from there and combined with the password I have to enter. If the key is there or anywhere even if I don't download the key I shall not be locked out the pool if I don't forget the password. I dont't have to upload any key as soon as usb memory is not corrupted or I have forgotten the password.

What I was saying is that the procedure described in the manual is to re encrypt master key, enter new password and re-download recovery and main key. Because of password is asked before disk replace and main key is in /data/geli or anywhere in the usb key after replacing an encrypted drive I can reboot the system with out rekeying or downloading anything if I remember the password. The new hard disk's master key is encrypted with the main key on the usb and the password I provide. Only recovery key does not work anymore.
What the manual says is that you *might* me unable to access the pool. Maybe there was a bug? Or the "might" is referred to whom forget the password?
I have done a test in a vm and I was able to access my data without re-keyng ( the test might be incomplete: did in a system without password set like my production systems - now I am asking myself if only root password is asked before replace or also key password mmmm...).

The real problem is another: even in 9.2.1.7 and 9.3 current systems I have still to edit the sql database every time a disk fails. I have done some test in the VM with 9.3 and everything works only if I am able to manually detach the hard disk.
In the last 18 monthes I had 7 (SEVER) Seagate 2TB hard drive failing over a population of about 16 units. They were made in different countries, china and thay but all same model name. Different firmware version, upgraded when possible.
Every time a Seagate failed I had to reboot to keep the server running: because of a swap portion is lost every time the GUI goes down but not the jails with the service (lucky?). So I decided to reboot. Seagate dies "well" and are not seen by the bios anymore and don't populate /dev so I can't detach 'em manually and that forces me to fix the db manually. I suppose this is a bug, what do you think?

Moreover the swap problem in annoying, it would be nice to have more ram ( ECC ;) but also giving swap some more robustness would be helpfull.

Thanks,

Alessandro

ps: isn't it weird that with swap lost only the GUI is crashing and not the jails????? 7 times over 7.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
ps: isn't it weird that with swap lost only the GUI is crashing and not the jails????? 7 times over 7.

Why in the world would that be strange?

In the UNIX virtual memory model, lightly used pages are the first to get swapped out when there's memory pressure. ZFS and jails are good at causing memory pressure. Would you prefer instead for pages from your jails to get swapped out? The system will naturally tend to prefer something for swapout that doesn't appear to be active, which, for many FreeNAS systems, would be the GUI. A jail, by way of comparison, is likely to be *doing* something.
 

John Doe

Guru
Joined
Aug 16, 2011
Messages
635
You are right in principle but it is also about granularity. It still surprise me that every process inside the jail is not swapped out. I don't see any service respawning, it looks like nothing inside the jail crashes.
Moreover I am talking about owncloud jails not created via plugin (never been able to upgrade via gui) which is using Apache (why??) but a self made portjail with nginx. Nginx is the same used bu freenas gui: do you know if jails uses COW also for memory model or if I am running completely different istances with all the code duplicated so that one is swapped and the other is not?

Ciao!
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,680
Well look at the process sizes by RES:

Code:
  PID USERNAME    THR PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
 4010 root          6  21    0   382M   214M usem    0   1:06   0.00% python2.7
 4014 root          1  20    0   205M 84704K select  2   0:37   0.00% python2.7
 5075 root          1  52    0   165M 61652K ttyin   1   0:01   0.00% python2.7
 4314 root          4  52    0   173M 60920K select  2   0:02   0.00% python2.7
 4099 root         12  20    0   154M 18068K uwait   3   2:35   0.00% collectd
 3694 root          1  20    0   256M 17204K select  0   0:03   0.00% smbd
 3717 root          1  20    0   242M 15772K select  0   0:00   0.00% winbindd
 3778 root          1  20    0   242M 15740K select  2   0:00   0.00% winbindd
 3786 root          1  20    0   248M 15344K select  1   0:00   0.00% winbindd
 3697 root          1  20    0   240M 14988K select  2   0:00   0.00% winbindd
 3691 root          1  20    0   209M 12684K select  1   0:02   0.00% nmbd
 5115 root          1  20    0 84344K 11120K kqread  0   0:03   0.00% syslog-ng


If you were swapper, wouldn't you look at those huge, piggy, 0% busy highly idle python jobs first?
 

ToBeFrank

Dabbler
Joined
Feb 20, 2015
Messages
41
What I was saying is that the procedure described in the manual is to re encrypt master key, enter new password and re-download recovery and main key. Because of password is asked before disk replace and main key is in /data/geli or anywhere in the usb key after replacing an encrypted drive I can reboot the system with out rekeying or downloading anything if I remember the password. The new hard disk's master key is encrypted with the main key on the usb and the password I provide. Only recovery key does not work anymore.

When looking at the procedures for how to replace an encrypted HD, I was greatly concerned that I would have to re-key after the resilver or I could lose the pool. A resilver could take a long time, which means during that time if anything happened that caused a reboot I wouldn't be able to re-key first. But, like you, I could not figure out why a re-key is necessary so I took a look at the source code. It turns out you and I are correct.

The code asks you for your password, then verifies you entered it correctly by decrypting the existing drives. If that fails, it assumes you entered the wrong password. If the password is correct, it then uses that password plus the existing key in /data/geli to set the master key on the replacement drive. It then decrypts the replacement drive making it ready for use and also verifying the password and key worked correctly. Therefore, a reboot after the resilver would not render your pool useless as long as you know the password.

You would, of course, need to set a new recovery key as the existing recovery key has not been set on the replacement drive. I think the docs need an update and should say that after replacing an encrypted drive, you need to set a new recovery key, either before or after the reboot. All of the other stuff can be removed as nothing else needs to be done as far as keys are concerned.

EDIT: removed part about not zeroing as cyberjock pointed out /tmp is a RAM drive
 
Last edited:

cyberjock

Inactive Account
Joined
Mar 25, 2012
Messages
19,526
This is NOT true. Both your password and the recovery key are written to files in /tmp. They are, of course, deleted when everything goes smoothly, but there is no exception handling to delete them if something goes wrong. The REALLY bad thing in this code is they don't overwrite the files with zeros before deleting them. If the boot filesystem is like other filesystems, a delete merely removes a pointer to the file. The data in the file is still on disk until something happens to overwrite it. If it never gets overwritten, someone who has your drive could recover both your password and your recovery key. I will file a bug report for this.

/tmp is a RAM drive.
 
Status
Not open for further replies.
Top