-
Notifications
You must be signed in to change notification settings - Fork 5
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
Comments
On the receiving host (192.168.1.30), what does |
|
That looks good. For the first error, |
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 |
The checks in I don't think this is the problem, but what does |
So for the first command, I get no value in return, and for the get readonly I get:
|
How about |
I get this, which, is my old existing snapshots before I set up zap
|
That's a problem. You will have to remove those snapshots so I will get back to you soon to address the permissions issue. |
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? |
If you are doing exactly If you want to try and salvage the replicated snapshots you could try this.
You will probably still run into the permission problems, but let's see what happens with this first before we move on. |
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. |
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? |
You are saying when you run |
iocage zap:snap on local 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 zfs snap iocage@ZAP_castleDefense_2017-10-09T10:53:09-0700--1d And here, the datasets with no mountpoint (data) are being denied |
It looks like whatever user you are using ( |
Looks like the zap user has permissions on the dataset:
|
Could you try |
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? |
I am not aware of issues taking snapshots of datasets without mount points.
You are definitely the user
|
Yes, I am definitely the user Here is my output:
|
|
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 |
zfs(8) describes the |
I decided to get a response from the iocage developer on the dataset, and he told me this:
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 |
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? |
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? |
You can access/restore individual files from the hidden |
Aha I'm seeing my mistake. I had to do |
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:
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
The text was updated successfully, but these errors were encountered: