ZFS Copy a dataset, containing Several Datasets, with Snapshots.

ZapDragon

ZapDragon

I have a single dataset that I am trying to move to a ZFS pool.
The Dataset itself does not contain data, but more datasets.

Code: 
vault/root       1.62T  8.08T   336K
vault/root/ds1   42.8G  8.08T   895M
vault/root/ds2   6.65G  8.08T   272M
vault/root/ds3   102M   8.08T   102M
vault/root/ds4   12.9G  8.08T  1.10G
vault/root/ds5   61.5G  8.08T  1005M
vault/root/ds6   316G   8.08T  3.70G
vault/root/ds7   99.0M  8.08T  99.0M
***
vault/root/ds31  30.0M  8.08T  30.0M
vault/root/ds32  13.0G  8.08T   314M
vault/root/ds33  33.6G  8.08T  5.31G

Each dataset contains constantly changing data, and as a precaution, a snapshot script was created for each of them.
Each dataset has hundreds if not thousands of snapshots. (Client did not want to merge snapshots, over time.)

What I am trying to do now, is copy the root dataset, and all of it's sub datasets and snapshots to a pool of their own.

How can I recursively copy vault/root to zpool2 and keep an identical copy of everything, including the snapshots?
 
You take the latest snapshot of the source and you send it with
Code: 
zfs send -R zpool/zfsfs@mylatest |
On the receiver side all incremental snapshots will be available.
 
Alain De Vos said:
You take the latest snapshot of the source and you send it with
Code: 
zfs send -R zpool/zfsfs@mylatest |
On the receiver side all incremental snapshots will be available.
Click to expand...
To be clear, if I take a snapshot in the dataset vault/root, and
Code: 
zfs send -R vault/root@mylatest | zfs recv
thiswill replicate that dataset and the sub-datasets, and their snapshots as well?
Or do I need to copy each of the individual datasets, one at a time?

vault/root does not actually have any data or snapshots. Its simply the location where all the other datasets are located.
 
You can replicate recursively, with syncoid if you are lazy.
Thousands of snapshots make everything slower, much slower.
In those cases I suggest to archive the snapshots into zpaq, then consolidate purging the older
 
There seems to be a very serious limitation. The destination must be a freshly created zfs filesystem without any snapshots.
I try to figger out why.

You must first destroy all snapshots on the destination and then on the receiving end you must force an unmount with parameter "-M".
This works but I don't find this solution nice.

I think taking a full snapshot.
Followed by sending all the increments, one-by-one, is much cleaner.
I use awk for book-keeping manipulations of the increment names.
And sending an increment is a very fast operation involving little bandwith.
Code: 
zfs send -i  ${previous} ${current} | zfs receive ${dest}
There is a drawback. If one incremental backup misses, all the following will fail.
 
There seems to be some confusion, so let me bullet some details.

- The Destination Pool (Archive) is Brand-new and contains no data.

- The Source is a dataset that ONLY contains other datasets, and those datasets have snapshots.

Code: 
vault/root
         vault/root/ds1
                          vault/root/ds1@exmaplesnap1
                          vault/root/ds1@exmaplesnap2
                          vault/root/ds1@exmaplesnap3
                          ***
                          vault/root/ds1@exmaplesnap1000
         vault/root/ds2
                          vault/root/ds2@exmaplesnap1
                          vault/root/ds2@exmaplesnap2
                          vault/root/ds2@exmaplesnap3
                          ***
                          vault/root/ds2@exmaplesnap1000
         vault/root/ds3
                          vault/root/ds3@exmaplesnap1
                          vault/root/ds3@exmaplesnap2
                          vault/root/ds3@exmaplesnap3
                          ***
                          vault/root/ds3@exmaplesnap1000

- I am needing to copy Everything at vault/root to the new pool (Archive), which is completely empty.

- My client does not want to remove any snapshots. This is non-optional. (I don't like it either, but hey. They are paying me for it.)

- Can I create a snapshot at vault/root@snapshot and zfs send that?

- Do I need to send each dataset one at a time?

- Can I see a command example? (zfs send -? vault/root | zfs recv -? archive)
 
The following works
Code: 
zpool set listsnapshots=on Archive
zfs destroy Archive/ds1
zfs create  Archive/ds1
zfs send -R vault/root/ds1@exmaplesnap1000 | zfs receive -F Archive/ds1
You see 1000 snapshots on the destination
Code: 
/sbin/zfs list -t snap -r | /usr/bin/grep Archive

Analog for ds2 ds3

I you also have a lot of ds1, ds2 , .... ds1000, you might be better of storing the destination in files
 
You can replicate with zfs send, but I suggest to use a free tool named syncoid to make it easier
You can copy say /tank and whatever snapshot live here to /replica/tank_copy without much hassle.

BUT you can also maintain the snapshot data (retain forever) into a special format archive from where you can restore, if needed, everything more than one year old (just an example) maintaining on line only last 365 snapshots (or whatever).
If you have thousands of snapshots you get heavy performance degrade.
Huge on spinning HDDs.
Even a directory travel (see what is in.. Zfs folder) will require minutes, even 25 or more on mid size server.
Ok I want to open the 2018-03-05 11:00:00 snapshot.
Good luck, you have to wait 25 minutes just to enter in this folder (just an example) hoping to do not get a timeout (ex if samba-condivide accessing from Windows client) by Explorer.
It is a common behavyour, I fight all the time

So if you have something real small (hundreds of file and some GB) then you can handle thousands of snapshots.
If you have hundred thousands files simply no.
You can try yourself.
For me that does not make any sense.
If you want to retain snapshot (thousands of) you can without impact with zpaq.
Caveat: restore will be slow, even hours.
Therefore a good balance is keep the last online, archive (not discard) the older.
Archive virtually forever, I have real world customers with 4 full years and 4.000 snapshot archived
 
For "hundreds and thousands of snapshots" I'd highly suggest also using the '-s' flag on the receiving side. You'll be transferring _A LOT_ of metadata, which can take a long time to send and replicate (prepare to see something like a few hundret kb/s transfer rate!), so you absolutely want to be able to resume the process in case something falls over (which unfortunately happens rather often with many snapshots).
I'd also pipe the send/receive through mbuffer to buffer the bursts which often occur with zfs send/receive, so you can make better use of available disk and network bandwidth.

Weeding out the snapshots might also be a good idea, i.e. only keeping monthlies/weeklies depending on their age. You might want to take a look at zfsnap(8) for automated creation and cleanup of snapshots.
 
I suggest zfSnap (with the S) for crontabbed-snapshot
 
You must log in or register to reply here.
Back
Top