Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some errors popping up doing zap rep #8

Closed
stratacast opened this issue Oct 1, 2017 · 29 comments
Closed

Some errors popping up doing zap rep #8

stratacast opened this issue Oct 1, 2017 · 29 comments

Comments

@stratacast
Copy link

I have been doing zap snapshots for a while on my server now, and finally set up a way to do remote replication with zap to another computer on my network with an external HDD plugged in. Both of these machines are running FreeBSD 11.1 and using the current version of zap from ports (0.7.3)

After running zap rep after following the instructions on the blog, I am getting errors such as this on various zfs datasets:

zfs send -I iocage@ZAP_castleDefense_2017-09-30T02:00:00-0700--3w iocage@ZAP_castleDefense_2017-10-01T02:00:00-0700--3w | ssh zap@192.168.10.30 "sh -c 'zfs recv -du -v backups/iocage'"
receiving incremental stream of iocage@ZAP_castleDefense_2017-10-01T02:00:00-0700--3w into backups/iocage@ZAP_castleDefense_2017-10-01T02:00:00-0700--3w
cannot receive incremental stream: most recent snapshot of backups/iocage does not
match incremental source
WARN: Failed to replicate iocage@ZAP_castleDefense_2017-10-01T02:00:00-0700--3w to zap@192.168.10.30:backups/iocage.
zfs send -I iocage/iocage@ZAP_castleDefense_2017-09-30T02:00:00-0700--3w iocage/iocage@ZAP_castleDefense_2017-10-01T02:00:00-0700--3w | ssh zap@192.168.10.30 "sh -c 'zfs recv -du -v backups/iocage'"

No remote snapshots found. Sending full stream.
zfs send -p iocage/iocage/jails/homeBackup/data@ZAP_castleDefense_2017-09-28T02:00:00-0700--3w | ssh zap@192.168.10.30 "sh -c 'zfs recv -Fu -v -d backups/iocage'"
warning: cannot send 'iocage/iocage/jails/homeBackup/data@ZAP_castleDefense_2017-09-28T02:00:00-0700--3w': permission denied
zfs bookmark iocage/iocage/jails/homeBackup/data@ZAP_castleDefense_2017-09-28T02:00:00-0700--3w iocage/iocage/jails/homeBackup/data#ZAP_castleDefense_2017-09-28T02:00:00-0700--3w
cannot create bookmark 'iocage/iocage/jails/homeBackup/data#ZAP_castleDefense_2017-09-28T02:00:00-0700--3w': unknown error
cannot open 'backups/iocage/iocage/jails/homeBackup/data': dataset does not exist
WARN: Failed to set canmount=noauto for zap@192.168.10.30:backups/iocage/iocage/jails/homeBackup/data

No remote snapshots found. Sending full stream.
zfs send -p iocage/iocage/jails/minecraft/data@ZAP_castleDefense_2017-09-28T02:00:00-0700--3w | ssh zap@192.168.10.30 "sh -c 'zfs recv -Fu -v -d backups/iocage'"

warning: cannot send 'iocage/iocage/jails/minecraft/data@ZAP_castleDefense_2017-09-28T02:00:00-0700--3w': permission denied

When I set up the permissions as specified on the source machine I only specified the zpool (iocage), and likewise with the remote system I specified the zpool (backups) as well as the dataset below (backups/iocage)

I also mounted my target zpool on an altroot with this:
zpool import -o altroot="/mnt/backupPool" backups

It appears I can see these settings on the zpools. I'm not sure what additional information to provide to solve this, if more is needed let me know and I can provide it

@Jehops
Copy link
Owner

Jehops commented Oct 1, 2017

On the receiving host (192.168.1.30), what does zfs allow backups/iocage say?

@stratacast
Copy link
Author

---- Permissions on backups/iocage -----------------------------------
Local+Descendent permissions:
user zap canmount,compression,create,mount,mountpoint,receive,refreservation,userprop,volmode
---- Permissions on backups ------------------------------------------
Local+Descendent permissions:
user zap canmount,compression,create,mount,mountpoint,receive,refreservation,userprop,volmode

@Jehops
Copy link
Owner

Jehops commented Oct 2, 2017

That looks good.

For the first error, cannot receive incremental stream: most recent snapshot of backups/iocage does not match incremental source, it sounds like you either removed @ZAP_castleDefense_2017-09-30T02:00:00-0700--3w from backups/iocage or created new snapshots there. Adding the -F flag when replicating will help if the receiving dataset has been modified. In most backup situations, I think it makes sense to always use the -F flag.

@stratacast
Copy link
Author

I think I see what you're saying. I haven't removed any snapshots, I'm letting zap handle that. I do have some non-zap snapshots on backups/iocage from prior to doing this. So would that then mean that those pre-existing snapshots are getting in the way and theoretically removing them would solve this issue? I will do -F from now on, I was doing -F before using zap

@Jehops
Copy link
Owner

Jehops commented Oct 2, 2017

The checks in zap's rep function should have caught any problems. On the receiving host, what does zfs list -rd1 -H -tsnap -o name -S creation backups/iocage 2>/dev/null | grep -m1 @ZAP_castleDefense_ show? It should be backups/iocage@ZAP_castleDefense_2017-09-30T02:00:00-0700--3w.

I don't think this is the problem, but what does zfs get readonly backups/iocage say?

@stratacast
Copy link
Author

So for the first command, I get no value in return, and for the get readonly I get:

backups/iocage readonly on local

@Jehops
Copy link
Owner

Jehops commented Oct 2, 2017

How about zfs list -rd1 -H -tsnap -o name -S creation backups/iocage 2>/dev/null without the grep?

@stratacast
Copy link
Author

I get this, which, is my old existing snapshots before I set up zap

backups/iocage@2017-09-24_19:45:20
backups/iocage@2017-09-18_18:26:54
backups/iocage@2017-09-12_00:10:55
backups/iocage@2017-09-07_23:00:29
backups/iocage@2017-09-03_20:12:00
backups/iocage@2017-08-28_11:34:54
backups/iocage@2017-08-21_17:39:03
backups/iocage@2017-08-21_01:52:47
backups/iocage@2017-08-20_23:35:10
backups/iocage@2017-08-20

@Jehops
Copy link
Owner

Jehops commented Oct 2, 2017

That's a problem. You will have to remove those snapshots so zap can send an initial full stream. zap should really have a better check for this scenario, so I just pushed a change.

I will get back to you soon to address the permissions issue.

@stratacast
Copy link
Author

Before I go destroying snapshots and possibly my only working backups: is the existing problems I'm having right now the reason why doing a "zfs list -t snapshot" won't bring up my zap backups?

@Jehops
Copy link
Owner

Jehops commented Oct 3, 2017

If you are doing exactly zfs list -t snapshot on the receiving side and you do not see any snapshots created by zap, then it sounds like they do not exist.

If you want to try and salvage the replicated snapshots you could try this.

  1. Ensure a local snapshot or bookmark exists for the youngest replicated snapshot. If one does not exist, you will have no choice but to delete replicated snapshots until the youngest one exists locally.
  2. Update your FreeBSD zap package to version 0.7.4, which I just committed.
  3. Rename the youngest replicated snapshot, so it confirms to the zap snapshot names. Something like zfs rename backups/iocage@2017-09-24_19:45:20 backups/iocage@ZAP_castleDefense_2017-09-24_19:45:20--3w should work. The corresponding local snapshot name must also conform to zap snapshot names. Use a TTL longer than 3w if you do not want zap destroy to remove it after three weeks.
  4. Replicate.

You will probably still run into the permission problems, but let's see what happens with this first before we move on.

@stratacast
Copy link
Author

I was having some trouble doing that (more just my lack of experience) so I just nuked my entire backup drive. I'll be safe (for now) with RAID as I get the ball rolling on this to figure out permissions issues

It still seems like I am missing permissions on some datasets for sending and unmount. Not too sure what that's all about.

@stratacast
Copy link
Author

After doing a quick glance: I see that zap snap is missing snapshots on some of my zfs datasets, even though zap:snap is set to on for those datasets. Namely, for iocage there is an order of iocage/iocage/jails/[jailname]/data, and it is missing on each one of those for each jail, even though they are zfs datasets. However, they don't have a mountpoint. Would that be causing the issue?

@Jehops
Copy link
Owner

Jehops commented Oct 8, 2017

You are saying when you run zap snap, snapshots are not being taken for datasets with the zap:snap property set to on? Could you show the output of zfs get -tfilesystem zap:snap and zap snap -v 1d?

@stratacast
Copy link
Author

iocage zap:snap on local
iocage/iocage zap:snap on local
iocage/iocage/download zap:snap on inherited from iocage/iocage
iocage/iocage/download/10.3-RELEASE zap:snap on inherited from iocage/iocage
iocage/iocage/download/11.1-RELEASE zap:snap on inherited from iocage/iocage
iocage/iocage/images zap:snap on inherited from iocage/iocage
iocage/iocage/jails zap:snap on inherited from iocage/iocage
iocage/iocage/jails/homeBackup zap:snap on inherited from iocage/iocage
iocage/iocage/jails/homeBackup/data zap:snap on inherited from iocage/iocage
iocage/iocage/jails/homeBackup/root zap:snap on inherited from iocage/iocage
iocage/iocage/jails/minecraft zap:snap on inherited from iocage/iocage
iocage/iocage/jails/minecraft/data zap:snap on inherited from iocage/iocage
iocage/iocage/jails/minecraft/root zap:snap on inherited from iocage/iocage
iocage/iocage/jails/nextcloud zap:snap on inherited from iocage/iocage
iocage/iocage/jails/nextcloud/data zap:snap on inherited from iocage/iocage
iocage/iocage/jails/nextcloud/root zap:snap on inherited from iocage/iocage
iocage/iocage/jails/website zap:snap on inherited from iocage/iocage
iocage/iocage/jails/website/data zap:snap on inherited from iocage/iocage
iocage/iocage/jails/website/root zap:snap on inherited from iocage/iocage
iocage/iocage/jails/plexMedia zap:snap on inherited from iocage/iocage
iocage/iocage/jails/plexMedia/data zap:snap on inherited from iocage/iocage
iocage/iocage/jails/plexMedia/root zap:snap on inherited from iocage/iocage
iocage/iocage/jails/reverseProxy zap:snap on inherited from iocage/iocage
iocage/iocage/jails/reverseProxy/data zap:snap on inherited from iocage/iocage
iocage/iocage/jails/reverseProxy/root zap:snap on inherited from iocage/iocage
iocage/iocage/jails/webServer zap:snap on inherited from iocage/iocage
iocage/iocage/jails/webServer/data zap:snap on inherited from iocage/iocage
iocage/iocage/jails/webServer/root zap:snap on inherited from iocage/iocage
iocage/iocage/log zap:snap on inherited from iocage/iocage
iocage/iocage/releases zap:snap on inherited from iocage/iocage
iocage/iocage/releases/10.3-RELEASE zap:snap on inherited from iocage/iocage
iocage/iocage/releases/10.3-RELEASE/root zap:snap on inherited from iocage/iocage
iocage/iocage/releases/11.1-RELEASE zap:snap on inherited from iocage/iocage
iocage/iocage/releases/11.1-RELEASE/root zap:snap on inherited from iocage/iocage
iocage/iocage/templates zap:snap on inherited from iocage/iocage
zroot zap:snap - -
zroot/ROOT zap:snap - -
zroot/ROOT/default zap:snap - -
zroot/tmp zap:snap - -
zroot/usr zap:snap - -
zroot/usr/home zap:snap - -
zroot/usr/ports zap:snap - -
zroot/usr/src zap:snap - -
zroot/var zap:snap - -
zroot/var/audit zap:snap - -
zroot/var/crash zap:snap - -
zroot/var/log zap:snap - -
zroot/var/mail zap:snap - -
zroot/var/tmp zap:snap - -

That is zap:snap on my entire filesystem. If you look at the "iocage/iocage/jails/[jailname]/data" datasets, you'll see zap:snap is on, but then here is zap snap -v 1d

zfs snap iocage@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/download@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/download/10.3-RELEASE@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/download/11.1-RELEASE@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/images@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/homeBackup@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/homeBackup/data@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
cannot create snapshots : permission denied
zfs snap iocage/iocage/jails/homeBackup/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/minecraft@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/minecraft/data@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
cannot create snapshots : permission denied
zfs snap iocage/iocage/jails/minecraft/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/nextcloud@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/nextcloud/data@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
cannot create snapshots : permission denied
zfs snap iocage/iocage/jails/nextcloud/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/norwestnetworks@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/norwestnetworks/data@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
cannot create snapshots : permission denied
zfs snap iocage/iocage/jails/norwestnetworks/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/plexMedia@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/plexMedia/data@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
cannot create snapshots : permission denied
zfs snap iocage/iocage/jails/plexMedia/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/reverseProxy@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/reverseProxy/data@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
cannot create snapshots : permission denied
zfs snap iocage/iocage/jails/reverseProxy/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/webServer@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/jails/webServer/data@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
cannot create snapshots : permission denied
zfs snap iocage/iocage/jails/webServer/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/log@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/releases@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/releases/10.3-RELEASE@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/releases/10.3-RELEASE/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/releases/11.1-RELEASE@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/releases/11.1-RELEASE/root@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d
zfs snap iocage/iocage/templates@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d

And here, the datasets with no mountpoint (data) are being denied

@Jehops
Copy link
Owner

Jehops commented Oct 9, 2017

It looks like whatever user you are using (zap?) to create the snapshots does not have permission to snapshot these datasets. You can check with, e.g., zfs allow iocage/iocage/jails/homeBackup/data. To add the snapshot permission for the user in question for the datasets in question, see here.

@stratacast
Copy link
Author

Looks like the zap user has permissions on the dataset:

---- Permissions on iocage/iocage ------------------------------------
Local+Descendent permissions:
        user zap bookmark,diff,hold,send,snapshot
---- Permissions on iocage -------------------------------------------
Local+Descendent permissions:
        user zap bookmark,diff,hold,send,snapshot

@Jehops
Copy link
Owner

Jehops commented Oct 11, 2017

Could you try zfs allow -u zap mount iocage, then try creating more snapshots to see if the permission issue is resolved?

@stratacast
Copy link
Author

No still having it. The thing with this zfs dataset is even though there's no mountpoint. I'm actually not even sure what the "data" dataset is there for. Perhaps this is something to also bring up with the iocage folks on iocage GH for those who want to do zfs snapshots of datasets & pools as non-root users?

@Jehops
Copy link
Owner

Jehops commented Oct 13, 2017

I am not aware of issues taking snapshots of datasets without mount points.

% sudo zfs create -o mountpoint=none -o canmount=off zroot/test
% sudo zfs allow -u zap bookmark,diff,hold,send,snapshot zroot/test
% sudo -u zap zap snap -v 1d zroot/test
zfs snap zroot/test@ZAP_phe_2017-10-13T10:08:05-0300--1d

You are definitely the user zap when you are running zap snap -v 1d? Let's compare your output of zfs get all iocage/iocage/jails/homeBackup/data with below.

% zfs get all zroot/test
NAME        PROPERTY              VALUE                  SOURCE
zroot/test  type                  filesystem             -
zroot/test  creation              Fri Oct 13 10:05 2017  -
zroot/test  used                  88K                    -
zroot/test  available             42.2G                  -
zroot/test  referenced            88K                    -
zroot/test  compressratio         1.00x                  -
zroot/test  mounted               no                     -
zroot/test  quota                 none                   default
zroot/test  reservation           none                   default
zroot/test  recordsize            128K                   default
zroot/test  mountpoint            none                   local
zroot/test  sharenfs              off                    default
zroot/test  checksum              on                     default
zroot/test  compression           lz4                    inherited from zroot
zroot/test  atime                 off                    inherited from zroot
zroot/test  devices               on                     default
zroot/test  exec                  on                     default
zroot/test  setuid                on                     default
zroot/test  readonly              off                    inherited from zroot
zroot/test  jailed                off                    default
zroot/test  snapdir               hidden                 default
zroot/test  aclmode               discard                default
zroot/test  aclinherit            restricted             default
zroot/test  canmount              off                    local
zroot/test  xattr                 on                     default
zroot/test  copies                1                      default
zroot/test  version               5                      -
zroot/test  utf8only              off                    -
zroot/test  normalization         none                   -
zroot/test  casesensitivity       sensitive              -
zroot/test  vscan                 off                    default
zroot/test  nbmand                off                    default
zroot/test  sharesmb              off                    default
zroot/test  refquota              none                   default
zroot/test  refreservation        none                   default
zroot/test  primarycache          all                    default
zroot/test  secondarycache        all                    default
zroot/test  usedbysnapshots       0                      -
zroot/test  usedbydataset         88K                    -
zroot/test  usedbychildren        0                      -
zroot/test  usedbyrefreservation  0                      -
zroot/test  logbias               latency                default
zroot/test  dedup                 off                    default
zroot/test  mlslabel                                     -
zroot/test  sync                  standard               default
zroot/test  refcompressratio      1.00x                  -
zroot/test  written               0                      -
zroot/test  logicalused           36.5K                  -
zroot/test  logicalreferenced     36.5K                  -
zroot/test  volmode               default                default
zroot/test  filesystem_limit      none                   default
zroot/test  snapshot_limit        none                   default
zroot/test  filesystem_count      none                   default
zroot/test  snapshot_count        none                   default
zroot/test  redundant_metadata    all                    default

@stratacast
Copy link
Author

Yes, I am definitely the user zap. Right now, from the root user I will do su zap to get to the zap user, and running whoami produces zap as the output.

Here is my output:

zfs get all iocage/iocage/jails/homeBackup/data
NAME                                 PROPERTY                VALUE                             SOURCE
iocage/iocage/jails/homeBackup/data  type                    filesystem                        -
iocage/iocage/jails/homeBackup/data  creation                Fri Sep  8 17:05 2017             -
iocage/iocage/jails/homeBackup/data  used                    88K                               -
iocage/iocage/jails/homeBackup/data  available               3.28T                             -
iocage/iocage/jails/homeBackup/data  referenced              88K                               -
iocage/iocage/jails/homeBackup/data  compressratio           1.00x                             -
iocage/iocage/jails/homeBackup/data  mounted                 no                                -
iocage/iocage/jails/homeBackup/data  quota                   none                              default
iocage/iocage/jails/homeBackup/data  reservation             none                              default
iocage/iocage/jails/homeBackup/data  recordsize              128K                              default
iocage/iocage/jails/homeBackup/data  mountpoint              none                              received
iocage/iocage/jails/homeBackup/data  sharenfs                off                               default
iocage/iocage/jails/homeBackup/data  checksum                on                                default
iocage/iocage/jails/homeBackup/data  compression             lz4                               received
iocage/iocage/jails/homeBackup/data  atime                   on                                default
iocage/iocage/jails/homeBackup/data  devices                 on                                default
iocage/iocage/jails/homeBackup/data  exec                    on                                default
iocage/iocage/jails/homeBackup/data  setuid                  on                                default
iocage/iocage/jails/homeBackup/data  readonly                off                               default
iocage/iocage/jails/homeBackup/data  jailed                  on                                local
iocage/iocage/jails/homeBackup/data  snapdir                 hidden                            default
iocage/iocage/jails/homeBackup/data  aclmode                 discard                           default
iocage/iocage/jails/homeBackup/data  aclinherit              restricted                        default
iocage/iocage/jails/homeBackup/data  canmount                on                                default
iocage/iocage/jails/homeBackup/data  xattr                   on                                default
iocage/iocage/jails/homeBackup/data  copies                  1                                 default
iocage/iocage/jails/homeBackup/data  version                 5                                 -
iocage/iocage/jails/homeBackup/data  utf8only                off                               -
iocage/iocage/jails/homeBackup/data  normalization           none                              -
iocage/iocage/jails/homeBackup/data  casesensitivity         sensitive                         -
iocage/iocage/jails/homeBackup/data  vscan                   off                               default
iocage/iocage/jails/homeBackup/data  nbmand                  off                               default
iocage/iocage/jails/homeBackup/data  sharesmb                off                               default
iocage/iocage/jails/homeBackup/data  refquota                none                              default
iocage/iocage/jails/homeBackup/data  refreservation          none                              default
iocage/iocage/jails/homeBackup/data  primarycache            all                               default
iocage/iocage/jails/homeBackup/data  secondarycache          all                               default
iocage/iocage/jails/homeBackup/data  usedbysnapshots         0                                 -
iocage/iocage/jails/homeBackup/data  usedbydataset           88K                               -
iocage/iocage/jails/homeBackup/data  usedbychildren          0                                 -
iocage/iocage/jails/homeBackup/data  usedbyrefreservation    0                                 -
iocage/iocage/jails/homeBackup/data  logbias                 latency                           default
iocage/iocage/jails/homeBackup/data  dedup                   off                               default
iocage/iocage/jails/homeBackup/data  mlslabel                                                  -
iocage/iocage/jails/homeBackup/data  sync                    standard                          default
iocage/iocage/jails/homeBackup/data  refcompressratio        1.00x                             -
iocage/iocage/jails/homeBackup/data  written                 0                                 -
iocage/iocage/jails/homeBackup/data  logicalused             11.5K                             -
iocage/iocage/jails/homeBackup/data  logicalreferenced       11.5K                             -
iocage/iocage/jails/homeBackup/data  volmode                 default                           default
iocage/iocage/jails/homeBackup/data  filesystem_limit        none                              default
iocage/iocage/jails/homeBackup/data  snapshot_limit          none                              default
iocage/iocage/jails/homeBackup/data  filesystem_count        none                              default
iocage/iocage/jails/homeBackup/data  snapshot_count          none                              default
iocage/iocage/jails/homeBackup/data  redundant_metadata      all                               default
iocage/iocage/jails/homeBackup/data  zap:rep                 zap@192.168.10.30:backups/iocage  inherited from iocage/iocage
iocage/iocage/jails/homeBackup/data  zap:snap                on                                inherited from iocage/iocage
iocage/iocage/jails/homeBackup/data  org.freebsd.ioc:active  yes                               inherited from iocage

@Jehops
Copy link
Owner

Jehops commented Oct 14, 2017

iocage/iocage/jails/homeBackup/data jailed on local
I think this is the problem.

Once a dataset is jailed, it can no longer be mounted on the host because the jail administrator may have set unacceptable mount points.

@stratacast
Copy link
Author

Aha! So is there then no way for a non-root user to snapshot jailed snapshots? Or can something be done about that? Or would the solution for ZAP to be have root do zap snap and then theoretically the zap user should be able to send the data without issue? Currently what I have had work successfully is to do a recursive snapshot as root and I've been able to do zfs send -R or zfs send -Ri for incremental to my external HDD that is locally imported to an altroot

@Jehops
Copy link
Owner

Jehops commented Oct 14, 2017

zfs(8) describes the jailed property to mean the dataset is to be managed from within the jail. The only solutions I am currently aware of are: 1. run zap snap as root (as you suggest), or 2. turn off the jailed property for these datasets.

@stratacast
Copy link
Author

I decided to get a response from the iocage developer on the dataset, and he told me this:

They were originally intended for users who wanted an easy dataset for zfs jailed datasets. The current iocage does not automatically create these, and should create them if needed. So feel free to nuke those!

So because these aren't necessary and a deprecated dataset, I think I'm going to nuke them and report back on zap, as I assume it should work after their removal

@stratacast
Copy link
Author

Success with all the sends and snaps, BUT. Still getting the mount problems and even with what appears to be otherwise successful sends, the disk space is being occupied but the snapshots aren't showing up, presumably because of the canmount that isn't working?

@stratacast
Copy link
Author

Update: mount problems are taken care of and I am now having 0 errors, I did not see that mountpoint had to be set to none. I would just like to know: how do I individually access each snapshot? I set a mountpoint for backups/iocage to access the snapshots, is there a different way in viewing or restoring my data via individual files and whole zfs datasets since this is all bookmarked data?

@Jehops
Copy link
Owner

Jehops commented Oct 18, 2017

You can access/restore individual files from the hidden .zfs directory for each dataset. Make sure you set the readonly property to on for all replicated datasets to prevent changes that will interfere with replication. You can also check out the clone and rollback subcommands of zfs for restoring.

@stratacast
Copy link
Author

Aha I'm seeing my mistake. I had to do zfs mount -a, which is having problems and forcing me to individually mount each zfs dataset manually, but I believe that is unrelated to this project. You have solved all my problems that I have encountered with this, and I am grateful. Thank you for the help and the software :)

@Jehops Jehops closed this as completed Oct 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants