Hi Stefan,
This is not a Gluster4 series, it is a design choice. This is the same
behavior in 3.x series also. When you restore a volume, we cannot use
the old path. Because we are not sure about the path at time when we
restore the volume. I will explain with an example.
Let's say you have 1*3 volume, and you took snapshot say snap1. Later
you decide to remove a brick and make the volume as 1*2. It is very much
possible that the removed brick will be deleted and/or mount point might
have reused for some other purpose. So when we restore the snap1, it
will have volume configuration as 1*3. If we use the same path, then the
third path is not in our gluster space.
To avoid this scenario, when a snapshot restore, we use the same
snapshot bricks. Ie volume bricks will make to point to snapshot brick.
Regards
Rafi KC
On 07/12/2018 01:47 PM, Stefan Kania wrote:>
> No one uses gluster 4.1.1 with snapshots?
>
>
> Am 10.07.18 um 14:11 schrieb Stefan Kania:
>> Hello,
>>
>> I just installed Gluster Version 4.1.1 from, the gluster.org
repository.
>> I tested the snapshot function and now I'm having the following
problem:
>>
>> When I do a "gluster volume info" BEFOR the snapshot I got:
>> ----------
>>
>> root at sambabuch-c2:~# gluster snapshot create snap1 gv1
>>
>> root at sambabuch-c2:~# gluster v info
>>
>> Volume Name: gv1
>> Type: Replicate
>> Volume ID: 43dcb41c-4893-4bbe-98fd-01f47810ee89
>> Status: Started
>> Snapshot Count: 0
>> Number of Bricks: 1 x 2 = 2
>> Transport-type: tcp
>> Bricks:
>> Brick1: knoten-1:/gluster/brick
>> Brick2: knoten-2:/gluster/brick
>> Options Reconfigured:
>> performance.client-io-threads: off
>> nfs.disable: on
>> transport.address-family: inet
>> ----------
>> The path in "Brick1:" and "Brick2" ist ok.
>> Then I revert to the snapshot with:
>> ---------
>>
>> root at sambabuch-c1:~# gluster volume stop gv1
>>
>> root at sambabuch-c1:~# gluster snapshot restore
snap1_GMT-2018.07.10-11.36.32
>>
>> root at sambabuch-c1:~# gluster v info
>>
>> Volume Name: gv1
>> Type: Replicate
>> Volume ID: 43dcb41c-4893-4bbe-98fd-01f47810ee89
>> Status: Started
>> Snapshot Count: 0
>> Number of Bricks: 1 x 2 = 2
>> Transport-type: tcp
>> Bricks:
>> Brick1:
>>
knoten-1:/run/gluster/snaps/ff8f9838466a4566a18fb74be82ed56d/brick1/brick
>> Brick2:
>>
knoten-2:/run/gluster/snaps/ff8f9838466a4566a18fb74be82ed56d/brick2/brick
>> Options Reconfigured:
>> performance.client-io-threads: off
>> nfs.disable: on
>> transport.address-family: inet
>> features.quota: off
>> features.inode-quota: off
>> features.quota-deem-statfs: off
>> ---------
>> As you can see, the path for "Brick1: " and "Brick2:
" has changed to
>> the path where the snapshot is located. How do I get the original path
>> back?
>> I have never seen this wit a Gluster-Version 3.x before.
>>
>> I use Debian 9. I created an LVM2 to take snapshots. The snapshots are
>> working, as long as I only mount the snapshot and copy some files out
of
>> the snapshot to the volume, everything is fine. Only if I revert a
>> snapshot I have the problem. Is there anything new I did not do? Or how
>> can I got my original path back?
>>
>> Thank's
>>
>> Stefan
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> https://lists.gluster.org/mailman/listinfo/gluster-users
>
> --
> Stefan Kania
> Landweg 13
> 25693 St. Michaelisdonn
>
>
> Signieren jeder E-Mail hilft Spam zu reduzieren. Signieren Sie ihre E-Mail.
Weiter Informationen unter http://www.gnupg.org
>
> Mein Schl?ssel liegt auf
>
> hkp://subkeys.pgp.net
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20180712/f0dc916a/attachment.html>