Where else would you back it up to? You need a pool, whether local or remote, to replicate a source dataset(s) to a target pool. (It can even be the same pool itself, but that’s silly, inefficient, and defeats the purpose of backups.)
If the “ColdStorage” SSH connection is configured properly, you should see a drop-down list on the “Destination” field.
If nothing shows up, it means there’s something misconfigured in your SSH connection.
that it is possible to send a encrypted pool?
to another turenas without the backup location having any key or passphrase of it. But still being encrypted.
When i created my Pool i encrypted it like posted above:
Main Pool (encrypted)
Dataset (encrypted by parent)
so i have to create a pool on the backup device:
Backup Pool (encrypted)
but than it tells me that i cant replicate into an already encrypted pool o.o
so is my goal looking like this? :
Backup Pool (encrypted backup?)
backed up Main Pool (encrypted)
backed up Dataset (encrypted by parent)
or do i only send datasets and ignore the pool of the machines all together?
But if so is it wise to even encrypt it? maybe only encrypt the datasets?
i think i am overwhelmed a little.
i guess LUKS and Keepass encryption are simpler than the truenas one o.o
To this day, from its inception, for some reason the ZFS developers have interwoven a pool’s name with the immutable root dataset’s name. This causes confusions between “pool” and “dataset”.
There is no such thing as replicating a pool.
What you want to do is replicate the dataset named “NAS”. (You’re not supposed to store anything directly in the root dataset “Main”, anyways.)
On the target field, you can select the target pool’s root dataset, and then manually append/NAS at the end of the text field.
This will instruct the Replication Task to do a full, recursive replication:
Main/NAS → Backup/NAS
This also assumes it will do a “raw” stream, so you can enjoy this feature:
Keep in mind, the target’s backup dataset (Backup/NAS) will become its own “encryrptionroot”, and can only be unlocked with the key/passphrase that is used to unlock it on the source.
If you mix things up, you can risk making it inaccessible to yourself, and thus it is no longer a true “backup”.
Your error is here.
ZFS can send an encrypted stream to a non-encrypted pool. The target system can still receive updates, and perform scrubs of the ZFS data structures. What the target system cannot do is decrypt the data. (Keep the keys safe!)
Dataset (encrypted but not unlockable without the pasphrase)
that sounds like exactly what i want.
Only thing now is that i dont get why my main pool is encrypted and the NAS Dataset is only “inherited” encryption.
is it wise to decrypt the pool and only encrypt the dataset?
is there any benefit in encrypting a pool if its only the “Basket” where all the datasets go into?
and again i am very great full for your explanations - i understand them much better then the documentation <3
That’s the confusion between pool and root dataset again. Encryption is dataset property: It is actually defined for the root dataset of the pool. And it would help if the root dataset of pool tank were automatically named tank.root rather than tank.
It actually does not matter if tank.root is encrypted and child datasets inherits this encrytion, or if tank.root is unencrypted but its child dataset private is encrypted. You should create your own dataset(s) and store everything in the child datset(s), not directly in the root dataset.
Leaving the root unencrypted makes it easier to have a mix of encrypted and unencrypted data in the pool, or different sets with different keys.
ok so i need to find a way to remove the encryption of everything i have so far.
than add encryption to my NAS dataset which lives in the main pool.
So that i can than replicate the encrypted NAS dataset to the backup pool .
where both pools are without encryption.
correct ?
is there an easy way to remove the encryption from my mainpool
Currently it looks like this:
Just dismiss the top-level root dataset (of any pool) as a glorified keychain. It serves no purpose other than a placeholder for the pool’s name and top-of-chain defaults.
You can do this, regardless if the top-level root dataset (of either pool) is encrypted or unencrypted.
You can’t “remove” encryption. Once set, it’s set for life. The only option would be to destroy the dataset. In this case, destroying the root dataset will destroy everything recursively, including the “NAS” dataset.
I know it sounds pedantic, but I have to stress again, you don’t encrypt pools. Encryption is a dataset property. (This is once again the confusion of “pools” and “root datasets”.)
ok i think i understand what you mean (:
(that the dataset and pool are different things like nest and eggs)
i am confused by the “unlocked by ancestor” part but from your explanation i think i got it.
i can change the passphrase or key for the pool and dataset independently.
i will try to only change the dataset passphrase.
than replicate it to another machine with its own pool (no encryption) .
destroy the original pool (and dataset).
create a new unencrypted pool and replicate the backup NAS Dataset to it.
That way i have only encrypted datasets in unencrypted pools.
and for the future only one passphrase to worry about (the one from the dataset) (:
