[SOLVED] How to snapshot an entire pool ?

[NinthWave]

I want to make a snapshot of the pool but it just take 1 second and the "referenced" is in bytes.

Is my pool badly configured ?

 

[Samuel Tai]

No, snapshots don't work like that. What you probably want to do is to recursively snapshot the root dataset, which will then create snapshots in all the daughters with the same timestamp.

 

[NinthWave]

No, snapshots don't work like that. What you probably want to do is to recursively snapshot the root dataset, which will then create snapshots in all the daughters with the same timestamp.

Yeah. I focused on the first line only.
After a longer look at the thing, I realized that's what happend. All datasets and child datasets have their own snapshot.
My bad.

 

[NinthWave]

And thanks

 

[NinthWave]

No, snapshots don't work like that. What you probably want to do is to recursively snapshot the root dataset, which will then create snapshots in all the daughters with the same timestamp.

I know I am hijacking my own thread but:
the goal is to prepare a second pool to be moved to a new backup server.
I am not sure I understand why I would use RSYNC over Replication or vice-versa ?

 

[Samuel Tai]

Replication is preferred if you need to carryover the data AND the snapshots. If you only need to carryover the data, rsync will suffice.

 

[Arwen]

Here is what I use to copy my OS root pool to an alternate media, (in case I need it for recovery).

Code:

zfs snapshot -r ${MY_SRC_POOL}@${MY_SNAP}

zfs send  -Rpv  ${MY_SRC_POOL}@${MY_SNAP} | \
  zfs receive -dFu ${MY_DEST_POOL}

zfs destroy -rv ${MY_SRC_POOL}@${MY_SNAP}
zfs destroy -rv ${MY_DEST_POOL}@${MY_SNAP}

It works to clone a source pool to the destination.

Always check your send & receive options to make sure they do what you want to do. My use case assumes an empty destination pool.

 

[sretalla]

Replication is preferred if you need to carryover the data AND the snapshots. If you only need to carryover the data, rsync will suffice.

Just to add a little precision...

rsync can't sync datasets, so if the target is ZFS and you don't want all your datasets to become directories on the target side, you must use replication (or paistakingly create the datasets first, then rsync into them).

 

[NinthWave]

Replication is preferred if you need to carryover the data AND the snapshots. If you only need to carryover the data, rsync will suffice.

Just to add a little precision...

rsync can't sync datasets, so if the target is ZFS and you don't want all your datasets to become directories on the target side, you must use replication (or paistakingly create the datasets first, then rsync into them).

I'd like to verify I understand correctly using this scenario

• Source pool: Bassin
• Destination pool: Sekurkopio

Initial procedure

• I snapshoted Bassin
• I used Replication to make my first "duplicate" of Bassin which indeed created all datasets.

From now on
I could use RSYNC scheduled tasks since all datasets from source to destination are an exact match.

but,

If at anytime I create a new dataset at the source and forget to manually create it at the destination or better, make an initial replication of said dataset, an RSYNC task will transfer the new dataset as a simple directory.

So,

If my goal is to have a synchronized copy of my NAS to a remote NAS as a failsafe on the fly in the unlikely but not impossible loss of the NAS, it is better to go the scheduled replication tasks ?

Thanks.

 

[blanchet]

Indeed you can create pool checkpoint with the command zpool checkpoint

Checkpoints are very similar to snapshots except that

• they operate at the pool level instead of the dataset or zvol level
• you cannot send or receive them.

This command is available only from the command line interface, it is not exposed in the web user interface

Manual

zpool-checkpoint.8 — OpenZFS documentation

openzfs.github.io

Article

https://freebsdfoundation.org/wp-content/uploads/2019/01/ZPool-Checkpoint.pdf

Tutorial 1

ZFS Storage Pool Checkpoint | Core Dump

Another article

zpool checkpoints

In March, to FreeBSD landed a very interesting feature called 'zpool checkpoints'. Before we jump straight into the topic, let's take a step back and look at another ZFS feature called ‘snapshot’. Snapshot allows us to create an image of our single file systems. This gives us the option to...

oshogbo.vexillium.org

 

[sretalla]

Checkpoints are very similar to snapshots except that

• they operate at the pool level instead of the dataset or zvol level
• you cannot send or receive them.

And they are VERY DIFFERENT in that you can only have one of them for any pool at a time.

They are really only intended for use as a point to fail back to after a pool upgrade or some other one-time pool-wide event.

 

[NinthWave]

@Samuel Tai @sretalla
This matter have been left on ice for a while but I am ready to migrate the "backup pool" in the remote server.

Unfortunately, I still cannot choose between RSYNC and REPLICATION since I don't know if it is necessary to copy the snapshot as well ???

So here is the goal again
I have the main NAS in one physical room.
I have the backup NAS in an other building but the 2 are on the same LAN (a cable is running between the two)
If for any reason, I lose the main server (burned to the ground), I'd like to redeploy the backup server with as little headache as possible.

Thanks

 

[Dice]

On top of my head, I cannot think of any reason why one would prefer rsync over replication if the goal is anywhere near this:

I lose the main server (burned to the ground), I'd like to redeploy the backup server with as little headache as possible.

 

[sretalla]

I don't know if it is necessary to copy the snapshot as well ???

A snapshot isn't as much what you copy as much as it is how you select what you copy.

It's really just a frozen in time version of what's in the dataset/pool.

Take a snapshot... replicate that snapshot... replica is identical to the source when the snapshot was taken.

If you replicate continuously, the snapshots will also be available on the target side and you could roll the target back to one of those points in time if that were somehow useful (or just access the .zfs/snapshot directories to get to older versions of files).

 

[NinthWave]

I believe it's the last thing.
The last checkbox (Almost), again not sure what it's doing

 

[sretalla]

With your stated aim, you should be checking that box.

It ensures that all (possible) properties are maintained through the replication process to the target side.