[Samba] shadow copy source

Wed Oct 12 01:38:22 UTC 2022

On Tue, Oct 11, 2022 at 4:07 AM Piviul via samba <samba at lists.samba.org> wrote:
>
> On 10/10/22 14:57, Piviul via samba wrote:
> > On 07/10/22 15:28, Nick Couchman via samba wrote:
> >> I would think this would be possible, yes, you'd just need to make
> >> sure that the rsync snapshots are put into a standard naming
> >> convention that can be translated by the vfs_shadow_copy2 module the
> >> date/time options it will present to Windows. You need the right
> >> combination of the following options to parse out those rsync
> >> directories:
> >>
> >> shadow:snapdir
> >> shadow:sort
> >> shadow:format
> >> shadow:snapprefix
> >> shadow:delimiter
> >
> > I never used shadow_copy2 VFS module... the rsync snapshots are in a
> > nfs share. I have mounted it on /home/shares-snapshots. The format I
> > use is the default value of shadow format value
> > ("@GMT-%Y.%m.%d-%H.%M.%S"). This is the content:
> >
> > $ ls /home/shares-snapshots/
> > @GMT-2022.10.07-05.25.01         @GMT-2022.10.07-11.07.01
> > @GMT-2022.10.07-14.07.01         @GMT-2022.10.07-17.07.01
> > @GMT-2022.10.10-11.07.01
> > @GMT-2022.10.07-05.25.01.log.gz  @GMT-2022.10.07-11.07.01.log.gz
> > @GMT-2022.10.07-14.07.01.log.gz  @GMT-2022.10.07-17.07.01.log.gz
> > @GMT-2022.10.10-11.07.01.log.gz
> > @GMT-2022.10.07-09.07.01         @GMT-2022.10.07-12.07.01
> > @GMT-2022.10.07-15.07.01         @GMT-2022.10.10-09.07.01
> > @GMT-2022.10.10-12.07.01
> > @GMT-2022.10.07-09.07.01.log.gz  @GMT-2022.10.07-12.07.01.log.gz
> > @GMT-2022.10.07-15.07.01.log.gz  @GMT-2022.10.10-09.07.01.log.gz
> > @GMT-2022.10.10-12.07.01.log.gz
> > @GMT-2022.10.07-10.07.01         @GMT-2022.10.07-13.07.02
> > @GMT-2022.10.07-16.07.02         @GMT-2022.10.10-10.07.01 latest
> > @GMT-2022.10.07-10.07.01.log.gz  @GMT-2022.10.07-13.07.02.log.gz
> > @GMT-2022.10.07-16.07.02.log.gz  @GMT-2022.10.10-10.07.01.log.gz
> >
> > for each hourly snapshot I have a log.gz file and a symbolic link
> > named latest that point to the latest snapshot. This structure should
> > be compatible is'nt it?
> >
> > So I have added to the smb.conf share section something like:
> >
> >     vfs objects = shadow_copy2
> >     shadow:snapdir = /home/shares-snapshots
> >     shadow:sort = desc
> >     # shadow:format = @GMT-%Y.%m.%d-%H.%M.%S
> >
> > I haven't set the shadow:delimiter and  shadow:snapprefix I haven't
> > understand how to set them... any way are not mandatory, aren't they?
> > Well, I have reload samba but from windows in the file properties no
> > versions are available... what I wrong?
>

My only experience using shadow_copy2 is with ZFS snapshots, so I had
to test up a small test environment to make sure this would actually
work - and it does. Here's what I did:
* Create a LVM volume and XFS filesystem and mount at /mnt/data, for
the main data.
* Create another LVM volume and XFS filesystem, and mount at
/mnt/snapshots, for the rsync/snapshot data.
* Run "rsync" a few times to sync up the data from /mnt/data to
/mnt/snapshots/$(date +%Y%m%d%H%M), creating the "snapshots"
* Configure Samba correctly and check Previous Versions. The relevant
share configuration is as follows:

[data]
        comment = Test Data Share
        path = /mnt/data
        admin users = DOMAIN\File_Server_Admins
        valid users = DOMAIN\File_Server_Admins DOMAIN\File_Server_Users
        vfs objects = shadow_copy2
        shadow:snapdir = /mnt/snapshots
        shadow:sort = desc
        shadow:format = %Y%m%d%H%M
        shadow:localtime = yes
        browseable = yes
        available = yes
        read only = no

I'm using both a different snapdir format and local timestamps instead
of GMT, so I put both those parameters - you probably won't need
either of them.

As far as why that works for me and your relatively similar setup
isn't working, here are a few things to look at:
* Make sure your NFS share permissions has valid permissions for all
of the users who will need to access the snapshots. I would guess that
access to the snapshot share and folders is done under the UNIX UID of
the user accessing Samba, so those UNIX accounts that the Samba users
map up to will need to be able to access the NFS snapshot directory.
You can verify this with something like "sudo -u testuser
/home/shares-snapshots/<SNAPSHOT>" and make sure that the user can
actually see it at the UNIX level.
* I've run into a scenario in at least some of my Samba systems where
the only users who can actually see the Previous Versions are ones who
are "admin users" for the share. I've not yet quite tracked down the
reason for this (had a thread on this mailing list a few months ago
about it) - something in my environment is blocking
"normal"/unprivileged users from seeing those Previous Versions. One
of these days I'll figure it out - might be ZFS permissions or
something like that.
* Your log output doesn't actually seem to contain much related to VFS
and the shadow_copy2 module. I'd suggest setting log level to
something like "3 vfs:10" which will force VFS to a higher level and
may get you something more useful. Also, if you're splitting out your
logs by machine or user, make sure you're looking at the correct log.

-Nick

> In your opinion I wrong some params in smb.conf or rsync snaphot can't
> be used as shadow copy?
>
> Piviul
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba