Restore encrypted offsite backup to unencrypted pool

[Theiaz]

Hi,

I’m pretty new to TrueNAS but i like it a lot!

Today I’ve tried to setup my local offsite backup to an external USB HDD. I’ve already setup the snapshot and replication tasks. The replication task has successfully transfered all snapshots to my backup-pool on the external HDD.

I want that my offsite backup is encrypted. Therefore the backup-pool is encrypted. My primary pool is not encrypted. Here is a overview:

The configuration of the replication task is the following:

Now i tried to restore the backup into my primary pool. To verify the backup i reset my primary pool to an older date (this morning). Now i want to restore the diffs since this morning by using the restoring functionaly of the replication task. This created me the following task:

However this task is failing with the following error message: “cannot receive incremental stream: cannot perform raw receive on top of existing unencrypted dataset.”

Isn’t is possible to store an encrypted backup and restore it to an unencrypted pool?

[Theiaz]

Sorry I’m not able to upload any images/screenshots…

[winnielinnie]

@Theiaz

I’m not able to upload any images/screenshots

I think I know what you’re trying to do, and how to do it, but screenshots will definitely help.

Usually backups are meant to be restored/used in full, rather than just transfer the “delta” back to the rolled-back source.

[winnielinnie]

Just to make sure.

1. You have an unencrypted dataset on your main pool
2. You want to keep it unencrypted
3. You want to have regular incremental backups from this main pool’s (unencrypted) dataset sent over to another pool’s (encrypted) dataset
4. You want to be able to rollback the main dataset to an earlier snapshot… and then “restore” (incrementally) from the backup dataset?

Why? In what situation would you intentionally rollback a dataset… only to have it rolled “forward” again from a backup source? Why rollback in the first place?

The main dataset will always dictate the snapshots and their orders, because you’ll never be using the backup dataset directly as a filesystem actively being written to. The moment you do that, it’s no longer a destination dataset for backups. (See the fourth flowchart in this post.)

[Theiaz]

Okay thanks so far. I’m a Soft undware Developer and I thought to use the snapshotting like Git😅.

This special usecase is just for testing purpose. I want to make sure that my backup ist working without wiping my main pool completely. I do not want to trust the mechasimn but also test it. Or do you recommend another approach?

[winnielinnie]

@Theiaz

I do not want to trust the mechasimn but also test it.

You can access the files and folders on the backup dataset(s) like any other ZFS dataset. Just make sure not to write anything into them.

This can be done via SSH, where you use the command-line to browse and list the files, or you can create a “readonly” SMB share to browse them in a user-friendly manner with a client’s file manager.

[Theiaz]

Thanks for your help so far!. And yes i already connected via ssh and can list the files. To make it clear, let me summarize.

1. The current approach for my backup is ok (unencrypted mainpool, with encrypted offsite backup to a backup pool). Or is it better to encrypt the mainpool aswell to avoid compability issues?

2. There is no need to test/verify if the backup has been successful or the dataset on the backup pool can be restored to the main pool. If you can access the backup filesystem it should be enough.

3. Furthermore, it is not desired to apply deltas (snapshots) to restore a backup incrementally. Instead you should make a all or nothing approach (copy the full backuped dataset to a new dataset on the mainpool).

However, how can i solve the above mentioned error: “cannot receive incremental stream: cannot perform raw receive on top of existing unencrypted dataset"? Should i ignore it, because the fact mentioned in 3.?

Edit: I’m now able to upload images and edit prior posts. I’ve added images to my first post.

[winnielinnie]

@Theiaz

Or is it better to encrypt the mainpool aswell to avoid compability issues?

This is what I do^[1], and you can leverage the ability of “raw streams”, which allows you to replicate to a target without the need to unlock either side, and the destination remains in a locked state.

For you to go this route would require starting over, since you cannot just “toggle” encryption on/off for a dataset.

---

@Theiaz

There is no need to test/verify if the backup has been successful or the dataset on the backup pool can be restored to the main pool.

It doesn’t hurt to regularly test and confirm. At minimum, you want to see if you can access the files and even load a few via a readonly dataset with a readonly share, such as photos and videos.

---

@Theiaz

it is not desired to apply deltas (snapshots) to restore a backup incrementally. Instead you should make a all or nothing approach

That’s not really the issue. What you were initially describing didn’t really make sense. (Not trying to sound rude.)

If the source dictates the snapshots, which are sent over to the destination, then under normal conditions you should never end up with a destination (backup) that is somehow “newer” than the source.

If you rollback a source dataset to an earlier date, then it’s expected that you will likewise force a rollback on the destination (backup) the next time a replication is sent over. (This is indeed what the recv -F option does. Otherwise, it will abort the replication because “the destination contains modifications that are newer than the source’s latest snapshot”.)

To rollback a source… and then “send back” the latest snapshots from a backup doesn’t make much sense. Why would you even rollback the source in the first place, if you’re just going to reverse “rollforward” again? Maybe for an “accidental” rollback, this could save you. (So can a pool “checkpoint”.)

But intentionally, under normal conditions? I don’t see the reason for doing this.

---

@Theiaz

how can i solve the above mentioned error: “cannot receive incremental stream: cannot perform raw receive on top of existing unencrypted dataset"?

Because you cannot overwrite an unencrypted dataset with an encrypted replication stream.

By using the “Include Dataset Properties” option, as seen in your screenshot, you are invoking a “raw stream” (-w) under the hood. A raw stream, for an encrypted dataset, sends over the raw, encrypted blocks of data.

---

@Theiaz

Should i ignore it, because the fact mentioned in 3.?

Correct. I think you need to look at ZFS snapshots and replications from a different approach. Don’t treat it like SVN or Git, or some file-based version control.

---

1. There are caveats to this, such as when you encrypt the root dataset (which you might think is the “pool”), you can no longer nest unencrypted datasets anywhere else in the pool. This is a safeguard put in place and enforced by TrueNAS. ↩︎

[Theiaz]

Thanks so much for your help and the detailed answer! I think i have to take care of mixing the terms (pools and dataset…). And you doesn’t sound rude, it makes things clear

So i need to think what my next step should be. Either encryption on both sides, which means i need to start over. Or i use unencrypted offsite backups.

If i took the first approach, the simplest solution could be to make a new encrypted dataset underneath my primary-“pool” (dataset ) and copy all the child datasets to this new parent dataset. Afterwards i could delete the old unencrypted datasets. The only downside would be the additional dataset layer, but I think this is bearable. I’ve also read that it isn’t a good idea at all to encrypt the root dataset, because you lose the ability to differentiate between encrypted and unencrypted datasets later on.

[winnielinnie]

@Theiaz

the simplest solution could be to make a new encrypted dataset underneath my primary-“pool” (dataset ) and copy all the child datasets to this new parent dataset.

This is possible, if you are comfortable with a main encrypted source. (You lose the keyfile or passphrase, and your data is gone forever.)

You can even replicate within a pool itself. (Not sure how it ill affect performance, since the same HDDs will need to read and write during the same strenuous stream of IO requests.)

---

@Theiaz

The only downside would be the additional dataset layer

What additional dataset layer?

---

@Theiaz

Or i use unencrypted offsite backups.

You can still use encrypted backups, as you have been doing.

[Theiaz]

@winnielinnie

What additional dataset layer?

I’ve meant the new encrypted dataset underneath “primary-pool”. If “primary-pool” would be encrypted I do not need this layer (assumimg that I have one dataset as parent and the remaining datasets are still located below it and inherits the encryption).

@winnielinnie

You can still use encrypted backups, as you have been doing.

Yes you are right. I think I’m currently OK with the fact that my NAS is not encrypted and only the backups are encrypted.

[winnielinnie]

@Theiaz

If “primary-pool” would be encrypted I do not need this layer

There’s still no “layer” in that sense of the word.

Whether or not the root dataset is encrypted has no bearing on the encryption of any datasets below it.

If the root dataset is unencrypted, you can still do as you please with its children.

The same is true even if the root dataset was encrypted, but TrueNAS will not allow unencrypted datasets anywhere on this pool. It is their implementation to prevent users from creating mount issues or making their files “disappear” if they lock encrypted datasets in the wrong order, or attempt to lock them while an unencrypted child is in use.

[Theiaz]

Thank you for the clarification. So currently I’m fine with my current approach