[Gluster-users] restoring brick on new server failes on glusterfs

[Atin Mukherjee]

On 11/20/2015 01:30 AM, Merlin Morgenstern wrote:
> I am triying to attach a brick from another server to a local gluster
> development server. Therfore I have done a dd from a snapshot on
> production and a dd on the lvm volume on development. Then I deleted the
> .glusterfs folder on root. 
> 
> Unfortunatelly forming a new brick failed nevertheless with the info
> that this brick is already part of a volume. (how does gluster know that?!)
This is because the brick has an extended attribute 'volume-id' set
which indicates that this brick has been already used by another volume.
You could clean this xattr or alternatively a 'force' option would
bypass this validation.

> 
> I then issued the following:
> 
> sudo setfattr -x trusted.gfid /bricks/staging/brick1/
> sudo setfattr -x trusted.glusterfs.volume-id /bricks/staging/brick1/
> sudo /etc/init.d/glusterfs-server restart
> 
> 
> Magically gluster still seems to know that this brick is from another
> server as it knows the peered gluster nodes which are aparently
> different on the dev server:
> 
> sudo gluster volume create staging
> node1:/bricks/staging/brick1
> 
> volume create: staging: failed: Staging failed on gs3. Error: Host node1
> is not in 'Peer in Cluster' state
> 
> Staging failed on gs2. Error: Host node1 is not in 'Peer in Cluster' state
> 
> Is there a way to achive a restorage of that brick on a new server?
> Thank you for any help on this.
The problem here is the brick which you want to restore to a cluster is
not part of the cluster. You'd first need to probe the server to make it
added in the trusted storage pool.
> 
> 
> 
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>