SearchFAQMemberlist Log in
Reply to topic Page 1 of 1
Directive question?
Author Message
Post Directive question? 
Hi,

Another stupid directive question. I want to back up everything under
/data/od/fhw
but for the gg1 subdirectory, I only want to include data under the
following two areas:

gg1/images/cloud
gg1/input

Otherwise, I want to skip everything else under gg1. I can think of two
solutions,
and wanted to ask for advice on this, and/or if there's a better way:

1. If I have one NSR client resource with the following save set:
/data/od/fhw

would this server side directive accomplish this ???:
<< /data/od/fhw/gg1 >>
+null: .?* *
<< /data/od/fhw/gg1/images/cloud >>
forget
<< /data/od/fhw/gg1/input >>
forget

The man page for nsr (`man -S 5 nsr`) says:

forget
Forget all inherited directives (those starting with a "+" in parent
directories)."

I'm not sure if the second two are inherited since they don't begin with
'./' ? The
example in the man page shows './blah-blah-blah'. Anyway, I'm assuming
I'd have
to have '+' in front of the 'null' to force it to process the next two
lines for 'images/cloud'
and 'input'; otherwise, if I use 'null' instead then it will just stop
on gg1 and not see the
two forget lines for the other two areas? That right? Also, ditto for
using 'skip' instead
of '+skip', correct?

I actually want to keep the index entries for those two areas under gg1,
so I was thinking
'null' instead of 'skip'.


2. I know I can accomplish this with two NSR client resources. Resource
1 could specify
the following save set:
/data/od/fhw

with a server side directive as:
<< /data/od/fhw/gg1 >>
+null: .?* *

Resource 2 could specify the following two save sets:
/data/od/fhw/gg1/images/cloud
/data/od/fhw/gg1/input

with the 'Unix standard directives'.

I think that will work, but I'd like to be able to do this with one NSR
client resource instead of two.

Thanks.

George


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Post  
To the best of my knowledge, excluding an upper level directory will not allow including items in a lower level directory.

If you really must use one client resource, may i suggest that you move the included directories to another branch of the directory tree.

View user's profile Send private message
Post Directive question? 
On 2011-12-15 11:23, bingo wrote:
To the best of my knowledge, excluding an upper level directory will not allow including items in a lower level directory.

If you really must use one client resource, may i suggest that you move the included directories to another branch of the directory tree.
I think the users want those two directories to remain under the current
path since its all related, but, yes, I see your point. Smile

But what then is the purpose of the 'forget' save environment
directive? In the man page for nsr (nsr(5)), it shows
the following example at the end:

# We can rebuild any .o files in /usr/src
# from sources except those in /usr/src/sys.
<< ./usr/src >>
+skip: *.o
<< ./usr/src/sys >>
forget

It seems, though, that it should be the other way around? I would
interpret this to mean
that any .o files under /usr/src/sys could be recovered but not those
under usr/src, i.e.
one level above. Do they have their remarks wrong then in this example,
or am I
misunderstanding its function?

Assuming they do have it explained wrong then maybe using a local
directive (.nsr) instead
would work to allow me to grab anything under /data/od/fhw, including
those two subdirectories,
but otherwise avoid everything else under /data/od/fhw/gg1:

Putting the following .nsr file under /data/od/fhw

<< ./gg1 >>
+null: .?* *
<< ./gg1/images/cloud >>
forget
<< ./gg1/input >>
forget

with the save set for the client still being /data/od/fhw. Maybe ???

George


+----------------------------------------------------------------------
|This was sent by carsten_reinfeld < at > avus-cr.de via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Post  
I have not really touched this area for a while but i think the so called "environment variables" just apply to the local directive files which may exist.

The other issue is that if you exclude a directory in an upper level then the file system walker will not even reach the lower level where it would read these files.

This would not be the first bug in the book Wink

View user's profile Send private message
Post Directive question? 
Is that a case where you would use the "null" directive rather than "skip"?

Dave Werth
Garmin AT, Inc.
Salem, Oregon

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of bingo
Sent: Thursday, December 15, 2011 10:28 AM
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: [Networker] Directive question?

I have not really touched this area for a while but i think the so called "environment variables" just apply to the local directive files which may exist.

The other issue is that if you exclude a directory in an upper level then the file system walker will not even reach the lower level where it would read these files.

This would not be the first bug in the book Wink

+----------------------------------------------------------------------
|This was sent by carsten_reinfeld < at > avus-cr.de via Backup Central.
|Forward SPAM to abuse < at > backupcentral.com.
+----------------------------------------------------------------------


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


________________________________

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

Thank you for your cooperation.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Post  
I would never use null. Why would you create an index entry or a file that you can't recover later?

There might be a good reason for using null but i can't really see it.

View user's profile Send private message
Post Directive question? 
I would never use null. Why would you create an index entry or a
file that you can't recover later?

To run a report showing users "See, we didn't backup these file types you
were told not to use. So no whining when we can't recover them".


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Post Directive question? 
On 12/15/11 2:54 PM, bingo wrote:
I would never use null. Why would you create an index entry or a file that you can't recover later?

There might be a good reason for using null but i can't really see it.

You have a client with a large filesystem that you break up into
multiple save sets for performance. Then you create a second client
definition for that same client and use "ALL" as the save set with a
directive that uses "null" to not backup all the save sets you know
about from the first client a second time. If you don't use "null" in
that second client, to actually recover the data you backed up with the
first client you have to specify at time after the first client ran and
before the second client ran to be able to recover the data at all!

Using "skip" in that instance is just being nasty to your customers...
oh, wait. I've got a couple customers that think 100TB is small...
Maybe, I just found a Christmas present for them <bwahahaha> ... oops...
bad sysadmin sneaking out again Wink

Frank


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Post Directive question? 
On 2011-12-16 04:52, Frank Swasey wrote:
On 12/15/11 2:54 PM, bingo wrote:
I would never use null. Why would you create an index entry or a file
that you can't recover later?

There might be a good reason for using null but i can't really see it.

You have a client with a large filesystem that you break up into
multiple save sets for performance. Then you create a second client
definition for that same client and use "ALL" as the save set with a
directive that uses "null" to not backup all the save sets you know
about from the first client a second time. If you don't use "null" in
that second client, to actually recover the data you backed up with
the first client you have to specify at time after the first client
ran and before the second client ran to be able to recover the data at
all!

This is usually the methodology that I've employed to deal with these
scenarios. Sometimes, I have a save set for non-static data, e.g.
/data/dir1 that's listed for one NSR client resource and then maybe
another one (possibly several) like /data/dir1/specific for the static
data (may be very large), used by another NSR client resource (same
client). If I don't see any incremental changes for the static save
set(s) then I won't run another full every month on it; otherwise, I
will or maybe a numeric if the changes were small, depending on
frequency. But I always keep it on incrementals just in case. But I use
the +null directive for the first save set to avoid this area and
capture the residual. I found the idea of 'forget' with a .nsr file
intriguing, though, because it could possibly allow me to do this with
one NSR client instance, but I found the documentation for nsr (5) not
so clear. I could, of course, play around with it and test it but didn't
really want to spend all that time, so that's why I posted -
particularly for any gotchas or pitfalls that you guys might know about
that might not be documented. But trying to get that to work sounds
suspect, so I think I'll just leave things as I've done them before.

Using "skip" in that instance is just being nasty to your customers...
oh, wait. I've got a couple customers that think 100TB is small...
Maybe, I just found a Christmas present for them <bwahahaha> ...
oops... bad sysadmin sneaking out again Wink

There are some areas that we do use skip on because our users tell us
not to back those areas up ever. But, yes, I have found that if you need
to recover data that was later skipped (or maybe it always is by another
resource), then you do have to be certain to set the time properly;
otherwise, it won't show up. I always use mminfo to get the exact time
in that case. Of course, one also has to be careful to set the time zone
correctly (e.g. UTC versus, say, EST/EDT, etc.). So I'll run mminfo on
one machine, using EST, to get the time, and then I'll run recover on
some other client, but using UTC, and then I don't see anything when I
set the same time, and then finally ... Eureka! Duh! Sheesh! That's hit
me several times ... sigh ...

George
Frank


type "signoff networker" in the body of the email. Please write to
networker-request < at > listserv.temple.edu if you have any problems with
this list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Post Saveset Restore 
Hi folks,

I need to restore data from a client that has been decommissioned. We still have the data as it's a 7 year retention and need to another server to data to another server.

1. What is the command to check the valid savesets for that client?
2. What steps need I follow to ensure I can restore the data to another server?

Thanks in advance.

Jerome



**********************************************************************
COMPUTACENTER PLC is registered in England and Wales with the registered number 03110569. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (UK) Limited is registered in England and Wales with the registered number 01584718. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (Mid-Market) Limited is registered in England and Wales with the registered number 3434654. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (FMS) Limited is registered in England and Wales with the registered number 3798091. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW

The contents of this email are intended for the named addressee only.
It contains information which may be confidential and which may also be privileged.
Unless you are the named addressee (or authorised to receive mail for the addressee) you may not copy or use it, or disclose it to anyone else.
If you receive it in error please notify us immediately and then destroy it.
Computacenter information is available from: http://www.computacenter.com
**********************************************************************


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

View user's profile Send private message
Post Saveset Restore 
Also, the client has been deleted to recover the license.

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Swartz, Jerome
Sent: 13 January 2012 18:00
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: [Networker] Saveset Restore

Hi folks,

I need to restore data from a client that has been decommissioned. We still have the data as it's a 7 year retention and need to another server to data to another server.

1. What is the command to check the valid savesets for that client?
2. What steps need I follow to ensure I can restore the data to another server?

Thanks in advance.

Jerome



**********************************************************************
COMPUTACENTER PLC is registered in England and Wales with the registered number 03110569. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (UK) Limited is registered in England and Wales with the registered number 01584718. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (Mid-Market) Limited is registered in England and Wales with the registered number 3434654. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (FMS) Limited is registered in England and Wales with the registered number 3798091. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW

The contents of this email are intended for the named addressee only.
It contains information which may be confidential and which may also be privileged.
Unless you are the named addressee (or authorised to receive mail for the addressee) you may not copy or use it, or disclose it to anyone else.
If you receive it in error please notify us immediately and then destroy it.
Computacenter information is available from: http://www.computacenter.com
**********************************************************************


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

View user's profile Send private message
Post Saveset Restore 
In regard to: Re: [Networker] Saveset Restore, Swartz, Jerome said (at...:

Also, the client has been deleted to recover the license.

This is all covered in the NetWorker documentation, which you should have,
so I'm not going to go into much depth with the steps.

Also, it's good form to give some information about your environment
(Networker version on your server, what platform it and the client in
question are), as some of the answers may depend on your environment.

You'll need to create the client again (don't add it to any groups when
you create it) and you'll need to be certain it's recreated using the same
client id that it had previously. If you don't make the client id match
what you had previously, your job will be more difficult -- still
possible, but more than likely you'll have a harder time getting help.

If you didn't save the client id, you should have, but you can recover it
with the first mminfo command I show.

Hi folks,

I need to restore data from a client that has been decommissioned. We
still have the data as it's a 7 year retention and need to another
server to data to another server.

I can't grok that last bit, but it likely doesn't change the answers
anyway.

1. What is the command to check the valid savesets for that client?

Start with mminfo. You probably want something like

mminfo -ot -q client=your_client_name_here \
-r 'clientid,volume,ssid,client,name,savetime,nsavetime,level'

Other report (-r) fields are described in the mminfo documentation. You
may also find fields like "totalsize" and "nfiles" interesting.

If you haven't already done so, create the client with the client id your
query returned. Make certain the name exactly matches the previous name
too, even if you have to first create an /etc/hosts entry on your
NetWorker server or add a temporary record to your DNS.

You will *also* want to check to see if you still have the index savesets
for that client. If you do, life will be easier. That query would be
something like

mminfo -ot -q client=your_networker_server_here,name=index:your_client_name_here \
-r 'volume,level,nsavetime,name'

2. What steps need I follow to ensure I can restore the data to another server?

Once the client is created, the next steps depend on whether you have the
client file indexes and whether you need to recover just a few files or
want entire savesets back.

Either way, though, since you want to recover the data to a different
client, you'll need to modify the client entry you just (re)created to
allow "Remote access" for the client that will actually recover the data.
You do that by modifying the "Remote access" field, it's in the "Globals
(2 of 2)" tab of the admin gui.

You now have a four or five way fork in the road. How you proceed depends
on a number of things.

If you need to browse the client and recover individual files whose paths
you don't know, then you need either 1, 2, or 3 below. Alternately, if
you don't need to browse, either because you want to recover everything
or because you know the exact paths for the files, you can skip 1-3 and
just do 4 or 5.

1) you still have the client file indexes because they were never deleted
from disk on your networker server. You can proceed right to running
recover on the client that will be recovering the data, telling it to
browse the index for the client you recreated by using the "-c
your_client_name_here" option.

2) you have the index savesets on tape. You can recover them using nsrck
-L7, but there may be some annoying additional steps needed, depending on
what version of the server you're running. Those steps used to be
documented in the knowledgebase article esg98649 on Powerlink, not certain
if that's still the most up-to-date one, but it's worth a look.

Once you have the client file index, you proceed with the recover -c
as described in 1.

3) you don't have the client file indexes at all, so they will need to
be rebuilt. Run "scanner -i" on the savesets you want to recover from,
and when the client file index is rebuilt for those savesets, proceed
with recover -c.

4) you don't need the client file indexes because you're going to recover
entire savesets. Use recover with the -c and -S <ssid> options, possibly
multiple -S <ssids> at once.

5) you don't need the client file indexes because you know the exact
path(s) of the file(s) you need to recover. I always used to perform
this procedure through the old (green) NetWorker Administrator GUI, so
I'm not certain how it's done these days, but I believe the thing to try
is recover with the -c and -a options, to specify the exact path to the
file(s) you want. If that doesn't work (because it turns out that -a
requires the client file index) then some additional research will be
required.

Good luck!

Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

View user's profile Send private message
Post Saveset Restore 
This brings to mind what I think would be a useful modification to NetWorker. That would be the ability to set clients to an "emeritus" status which would allow retention of the information for a client for potential restores later but would not allow backing up the client and would not use up an active license.

Dave Werth
Garmin AT, Inc.
Salem, Oregon

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Swartz, Jerome
Sent: Friday, January 13, 2012 8:13 AM
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] Saveset Restore

Also, the client has been deleted to recover the license.

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Swartz, Jerome
Sent: 13 January 2012 18:00
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: [Networker] Saveset Restore

Hi folks,

I need to restore data from a client that has been decommissioned. We still have the data as it's a 7 year retention and need to another server to data to another server.

1. What is the command to check the valid savesets for that client?
2. What steps need I follow to ensure I can restore the data to another server?

Thanks in advance.

Jerome


________________________________

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies.

Thank you for your cooperation.


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

Post Saveset Restore 
Thanks for all the info Tim., its much appreciated. I am sure i cannot go wrong with all the infomation supplied.

________________________________________
From: EMC NetWorker discussion [NETWORKER < at > LISTSERV.TEMPLE.EDU] On Behalf Of Tim Mooney [Tim.Mooney < at > NDSU.EDU]
Sent: Friday, January 13, 2012 8:52 PM
To: NETWORKER < at > LISTSERV.TEMPLE.EDU
Subject: Re: [Networker] Saveset Restore

In regard to: Re: [Networker] Saveset Restore, Swartz, Jerome said (at...:

Also, the client has been deleted to recover the license.

This is all covered in the NetWorker documentation, which you should have,
so I'm not going to go into much depth with the steps.

Also, it's good form to give some information about your environment
(Networker version on your server, what platform it and the client in
question are), as some of the answers may depend on your environment.

You'll need to create the client again (don't add it to any groups when
you create it) and you'll need to be certain it's recreated using the same
client id that it had previously. If you don't make the client id match
what you had previously, your job will be more difficult -- still
possible, but more than likely you'll have a harder time getting help.

If you didn't save the client id, you should have, but you can recover it
with the first mminfo command I show.

Hi folks,

I need to restore data from a client that has been decommissioned. We
still have the data as it's a 7 year retention and need to another
server to data to another server.

I can't grok that last bit, but it likely doesn't change the answers
anyway.

1. What is the command to check the valid savesets for that client?

Start with mminfo. You probably want something like

mminfo -ot -q client=your_client_name_here \
-r 'clientid,volume,ssid,client,name,savetime,nsavetime,level'

Other report (-r) fields are described in the mminfo documentation. You
may also find fields like "totalsize" and "nfiles" interesting.

If you haven't already done so, create the client with the client id your
query returned. Make certain the name exactly matches the previous name
too, even if you have to first create an /etc/hosts entry on your
NetWorker server or add a temporary record to your DNS.

You will *also* want to check to see if you still have the index savesets
for that client. If you do, life will be easier. That query would be
something like

mminfo -ot -q client=your_networker_server_here,name=index:your_client_name_here \
-r 'volume,level,nsavetime,name'

2. What steps need I follow to ensure I can restore the data to another server?

Once the client is created, the next steps depend on whether you have the
client file indexes and whether you need to recover just a few files or
want entire savesets back.

Either way, though, since you want to recover the data to a different
client, you'll need to modify the client entry you just (re)created to
allow "Remote access" for the client that will actually recover the data.
You do that by modifying the "Remote access" field, it's in the "Globals
(2 of 2)" tab of the admin gui.

You now have a four or five way fork in the road. How you proceed depends
on a number of things.

If you need to browse the client and recover individual files whose paths
you don't know, then you need either 1, 2, or 3 below. Alternately, if
you don't need to browse, either because you want to recover everything
or because you know the exact paths for the files, you can skip 1-3 and
just do 4 or 5.

1) you still have the client file indexes because they were never deleted
from disk on your networker server. You can proceed right to running
recover on the client that will be recovering the data, telling it to
browse the index for the client you recreated by using the "-c
your_client_name_here" option.

2) you have the index savesets on tape. You can recover them using nsrck
-L7, but there may be some annoying additional steps needed, depending on
what version of the server you're running. Those steps used to be
documented in the knowledgebase article esg98649 on Powerlink, not certain
if that's still the most up-to-date one, but it's worth a look.

Once you have the client file index, you proceed with the recover -c
as described in 1.

3) you don't have the client file indexes at all, so they will need to
be rebuilt. Run "scanner -i" on the savesets you want to recover from,
and when the client file index is rebuilt for those savesets, proceed
with recover -c.

4) you don't need the client file indexes because you're going to recover
entire savesets. Use recover with the -c and -S <ssid> options, possibly
multiple -S <ssids> at once.

5) you don't need the client file indexes because you know the exact
path(s) of the file(s) you need to recover. I always used to perform
this procedure through the old (green) NetWorker Administrator GUI, so
I'm not certain how it's done these days, but I believe the thing to try
is recover with the -c and -a options, to specify the exact path to the
file(s) you want. If that doesn't work (because it turns out that -a
requires the client file index) then some additional research will be
required.

Good luck!

Tim
--
Tim Mooney Tim.Mooney < at > ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, IACC Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

**********************************************************************
COMPUTACENTER PLC is registered in England and Wales with the registered number 03110569. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (UK) Limited is registered in England and Wales with the registered number 01584718. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (Mid-Market) Limited is registered in England and Wales with the registered number 3434654. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW
COMPUTACENTER (FMS) Limited is registered in England and Wales with the registered number 3798091. Its registered office is at Hatfield Business Park, Hatfield Avenue, Hatfield, Hertfordshire AL10 9TW

The contents of this email are intended for the named addressee only.
It contains information which may be confidential and which may also be privileged.
Unless you are the named addressee (or authorised to receive mail for the addressee) you may not copy or use it, or disclose it to anyone else.
If you receive it in error please notify us immediately and then destroy it.
Computacenter information is available from: http://www.computacenter.com
**********************************************************************


via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

View user's profile Send private message
Display posts from previous:
Reply to topic Page 1 of 1
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
  


Magic SEO URL for phpBB