My current topology in WSS is one top level site with many subsites - only
one content database which is almost 38 GB.

I'm in the process of breaking up some of the subsite chains and creating
new top level sites. I'm also creating new content databases along the way,
trying to keep them around 2 GB.

While using smigrate to move some of these sites, I've noticed that when I
ran the restore, it was restoring the selected site correctly, but the
subsites were not restored. After the restore finished and I navigated to the
new site and found the the subsites were created, but when navigating to them
I was prompted to choose a template.

I got around this by using smigrate for each individual subsite, but its
taking quite a long time. I've found that when I restore one of the subsites,
I have the same problem if that subsite had children. It seems that although
I am backing up subsites, I'm not restoring them.

Does anyone know if this is due to the size of the sites, or maybe the
amount of time necessary to fully restore the site chain.

Thanks

RE: SMigrate Restore looses subsites by DaveCohoon

DaveCohoon
Thu Jun 08 14:05:03 CDT 2006

I've noticed in the log that I get the following error for each subsite,
right after the manifest has finished sending:

The server connection timed out.

I've set the timeout in IIS to 65000 seconds, is there something else I'm
missing?

"Dave Cohoon" wrote:

> My current topology in WSS is one top level site with many subsites - only
> one content database which is almost 38 GB.
>
> I'm in the process of breaking up some of the subsite chains and creating
> new top level sites. I'm also creating new content databases along the way,
> trying to keep them around 2 GB.
>
> While using smigrate to move some of these sites, I've noticed that when I
> ran the restore, it was restoring the selected site correctly, but the
> subsites were not restored. After the restore finished and I navigated to the
> new site and found the the subsites were created, but when navigating to them
> I was prompted to choose a template.
>
> I got around this by using smigrate for each individual subsite, but its
> taking quite a long time. I've found that when I restore one of the subsites,
> I have the same problem if that subsite had children. It seems that although
> I am backing up subsites, I'm not restoring them.
>
> Does anyone know if this is due to the size of the sites, or maybe the
> amount of time necessary to fully restore the site chain.
>
> Thanks

Re: SMigrate Restore looses subsites by Todd

Todd
Thu Jun 08 15:37:30 CDT 2006

Smigrate has some deficiencies, you've just stumbled onto one. We got
timeouts with it, but I thought setting the timeout to its max fixed that.
Did you set that in web.config or in IIS somewhere? Also, smigrate doesn't
support webs larger than 2 GB.

Since you're resizing, let me suggestion Content DBs a little larger than 2
GB. The only reason to break up Content DBs is to shorten your restore
window, should you have to restore an entire database. Depending on what
your SLA is with your users you might be able to get away with larger
databases. We run ours between 25 and 50 GB. SQL and WSS can certainly
both handle DBs that size with no trouble. Breaking 38 GB into 2 GB chunks
will get you 19 Content DBs and growing. That seems like more work than
it's worth.

tk
"Dave Cohoon" <DaveCohoon@discussions.microsoft.com> wrote in message
news:4367A0AE-4F47-4CDC-B2B9-569D1CF5D840@microsoft.com...
> I've noticed in the log that I get the following error for each subsite,
> right after the manifest has finished sending:
>
> The server connection timed out.
>
> I've set the timeout in IIS to 65000 seconds, is there something else I'm
> missing?
>
> "Dave Cohoon" wrote:
>
>> My current topology in WSS is one top level site with many subsites -
>> only
>> one content database which is almost 38 GB.
>>
>> I'm in the process of breaking up some of the subsite chains and creating
>> new top level sites. I'm also creating new content databases along the
>> way,
>> trying to keep them around 2 GB.
>>
>> While using smigrate to move some of these sites, I've noticed that when
>> I
>> ran the restore, it was restoring the selected site correctly, but the
>> subsites were not restored. After the restore finished and I navigated to
>> the
>> new site and found the the subsites were created, but when navigating to
>> them
>> I was prompted to choose a template.
>>
>> I got around this by using smigrate for each individual subsite, but its
>> taking quite a long time. I've found that when I restore one of the
>> subsites,
>> I have the same problem if that subsite had children. It seems that
>> although
>> I am backing up subsites, I'm not restoring them.
>>
>> Does anyone know if this is due to the size of the sites, or maybe the
>> amount of time necessary to fully restore the site chain.
>>
>> Thanks



Re: SMigrate Restore looses subsites by DaveCohoon

DaveCohoon
Thu Jun 08 16:17:01 CDT 2006

Thanks Todd.

I was aware of the 2GB limit - but thought that was only for wss v1, whereas
I'm using wss v2 sp2. I guess that I should probably let my content db's grow
more - although I still need to move these sites to have more than one top
level.

"Todd Klindt" wrote:

> Smigrate has some deficiencies, you've just stumbled onto one. We got
> timeouts with it, but I thought setting the timeout to its max fixed that.
> Did you set that in web.config or in IIS somewhere? Also, smigrate doesn't
> support webs larger than 2 GB.
>
> Since you're resizing, let me suggestion Content DBs a little larger than 2
> GB. The only reason to break up Content DBs is to shorten your restore
> window, should you have to restore an entire database. Depending on what
> your SLA is with your users you might be able to get away with larger
> databases. We run ours between 25 and 50 GB. SQL and WSS can certainly
> both handle DBs that size with no trouble. Breaking 38 GB into 2 GB chunks
> will get you 19 Content DBs and growing. That seems like more work than
> it's worth.
>
> tk
> "Dave Cohoon" <DaveCohoon@discussions.microsoft.com> wrote in message
> news:4367A0AE-4F47-4CDC-B2B9-569D1CF5D840@microsoft.com...
> > I've noticed in the log that I get the following error for each subsite,
> > right after the manifest has finished sending:
> >
> > The server connection timed out.
> >
> > I've set the timeout in IIS to 65000 seconds, is there something else I'm
> > missing?
> >
> > "Dave Cohoon" wrote:
> >
> >> My current topology in WSS is one top level site with many subsites -
> >> only
> >> one content database which is almost 38 GB.
> >>
> >> I'm in the process of breaking up some of the subsite chains and creating
> >> new top level sites. I'm also creating new content databases along the
> >> way,
> >> trying to keep them around 2 GB.
> >>
> >> While using smigrate to move some of these sites, I've noticed that when
> >> I
> >> ran the restore, it was restoring the selected site correctly, but the
> >> subsites were not restored. After the restore finished and I navigated to
> >> the
> >> new site and found the the subsites were created, but when navigating to
> >> them
> >> I was prompted to choose a template.
> >>
> >> I got around this by using smigrate for each individual subsite, but its
> >> taking quite a long time. I've found that when I restore one of the
> >> subsites,
> >> I have the same problem if that subsite had children. It seems that
> >> although
> >> I am backing up subsites, I'm not restoring them.
> >>
> >> Does anyone know if this is due to the size of the sites, or maybe the
> >> amount of time necessary to fully restore the site chain.
> >>
> >> Thanks
>
>
>

Re: SMigrate Restore looses subsites by Engelbert

Engelbert
Thu Jun 08 23:34:48 CDT 2006

> I was aware of the 2GB limit - but thought that was only for wss v1

There's no 2GB limit on the database which is probably what you are thinking
of.

(WMSDE has no limits on the db size)

Todd is talking about a smigrate limit..

Engelbert

"Dave Cohoon" <DaveCohoon@discussions.microsoft.com> wrote in message
news:685A0342-8A8B-4F25-911D-1A87AB28FB77@microsoft.com...
> Thanks Todd.
>
> I was aware of the 2GB limit - but thought that was only for wss v1,
> whereas
> I'm using wss v2 sp2. I guess that I should probably let my content db's
> grow
> more - although I still need to move these sites to have more than one top
> level.
>
> "Todd Klindt" wrote:
>
>> Smigrate has some deficiencies, you've just stumbled onto one. We got
>> timeouts with it, but I thought setting the timeout to its max fixed
>> that.
>> Did you set that in web.config or in IIS somewhere? Also, smigrate
>> doesn't
>> support webs larger than 2 GB.
>>
>> Since you're resizing, let me suggestion Content DBs a little larger than
>> 2
>> GB. The only reason to break up Content DBs is to shorten your restore
>> window, should you have to restore an entire database. Depending on what
>> your SLA is with your users you might be able to get away with larger
>> databases. We run ours between 25 and 50 GB. SQL and WSS can certainly
>> both handle DBs that size with no trouble. Breaking 38 GB into 2 GB
>> chunks
>> will get you 19 Content DBs and growing. That seems like more work than
>> it's worth.
>>
>> tk
>> "Dave Cohoon" <DaveCohoon@discussions.microsoft.com> wrote in message
>> news:4367A0AE-4F47-4CDC-B2B9-569D1CF5D840@microsoft.com...
>> > I've noticed in the log that I get the following error for each
>> > subsite,
>> > right after the manifest has finished sending:
>> >
>> > The server connection timed out.
>> >
>> > I've set the timeout in IIS to 65000 seconds, is there something else
>> > I'm
>> > missing?
>> >
>> > "Dave Cohoon" wrote:
>> >
>> >> My current topology in WSS is one top level site with many subsites -
>> >> only
>> >> one content database which is almost 38 GB.
>> >>
>> >> I'm in the process of breaking up some of the subsite chains and
>> >> creating
>> >> new top level sites. I'm also creating new content databases along the
>> >> way,
>> >> trying to keep them around 2 GB.
>> >>
>> >> While using smigrate to move some of these sites, I've noticed that
>> >> when
>> >> I
>> >> ran the restore, it was restoring the selected site correctly, but the
>> >> subsites were not restored. After the restore finished and I navigated
>> >> to
>> >> the
>> >> new site and found the the subsites were created, but when navigating
>> >> to
>> >> them
>> >> I was prompted to choose a template.
>> >>
>> >> I got around this by using smigrate for each individual subsite, but
>> >> its
>> >> taking quite a long time. I've found that when I restore one of the
>> >> subsites,
>> >> I have the same problem if that subsite had children. It seems that
>> >> although
>> >> I am backing up subsites, I'm not restoring them.
>> >>
>> >> Does anyone know if this is due to the size of the sites, or maybe the
>> >> amount of time necessary to fully restore the site chain.
>> >>
>> >> Thanks
>>
>>
>>



Re: SMigrate Restore looses subsites by Todd

Todd
Fri Jun 09 09:30:21 CDT 2006

Yeah, no limit on databases.

If you have a site that is 4 GB and you try to back it up with smigrate
you're going to have problems.

tk
"Engelbert" <Engelbert@discussions.nospam.com> wrote in message
news:eA6UW43iGHA.4276@TK2MSFTNGP03.phx.gbl...
>> I was aware of the 2GB limit - but thought that was only for wss v1
>
> There's no 2GB limit on the database which is probably what you are
> thinking of.
>
> (WMSDE has no limits on the db size)
>
> Todd is talking about a smigrate limit..
>
> Engelbert
>
> "Dave Cohoon" <DaveCohoon@discussions.microsoft.com> wrote in message
> news:685A0342-8A8B-4F25-911D-1A87AB28FB77@microsoft.com...
>> Thanks Todd.
>>
>> I was aware of the 2GB limit - but thought that was only for wss v1,
>> whereas
>> I'm using wss v2 sp2. I guess that I should probably let my content db's
>> grow
>> more - although I still need to move these sites to have more than one
>> top
>> level.
>>
>> "Todd Klindt" wrote:
>>
>>> Smigrate has some deficiencies, you've just stumbled onto one. We got
>>> timeouts with it, but I thought setting the timeout to its max fixed
>>> that.
>>> Did you set that in web.config or in IIS somewhere? Also, smigrate
>>> doesn't
>>> support webs larger than 2 GB.
>>>
>>> Since you're resizing, let me suggestion Content DBs a little larger
>>> than 2
>>> GB. The only reason to break up Content DBs is to shorten your restore
>>> window, should you have to restore an entire database. Depending on
>>> what
>>> your SLA is with your users you might be able to get away with larger
>>> databases. We run ours between 25 and 50 GB. SQL and WSS can certainly
>>> both handle DBs that size with no trouble. Breaking 38 GB into 2 GB
>>> chunks
>>> will get you 19 Content DBs and growing. That seems like more work than
>>> it's worth.
>>>
>>> tk
>>> "Dave Cohoon" <DaveCohoon@discussions.microsoft.com> wrote in message
>>> news:4367A0AE-4F47-4CDC-B2B9-569D1CF5D840@microsoft.com...
>>> > I've noticed in the log that I get the following error for each
>>> > subsite,
>>> > right after the manifest has finished sending:
>>> >
>>> > The server connection timed out.
>>> >
>>> > I've set the timeout in IIS to 65000 seconds, is there something else
>>> > I'm
>>> > missing?
>>> >
>>> > "Dave Cohoon" wrote:
>>> >
>>> >> My current topology in WSS is one top level site with many subsites -
>>> >> only
>>> >> one content database which is almost 38 GB.
>>> >>
>>> >> I'm in the process of breaking up some of the subsite chains and
>>> >> creating
>>> >> new top level sites. I'm also creating new content databases along
>>> >> the
>>> >> way,
>>> >> trying to keep them around 2 GB.
>>> >>
>>> >> While using smigrate to move some of these sites, I've noticed that
>>> >> when
>>> >> I
>>> >> ran the restore, it was restoring the selected site correctly, but
>>> >> the
>>> >> subsites were not restored. After the restore finished and I
>>> >> navigated to
>>> >> the
>>> >> new site and found the the subsites were created, but when navigating
>>> >> to
>>> >> them
>>> >> I was prompted to choose a template.
>>> >>
>>> >> I got around this by using smigrate for each individual subsite, but
>>> >> its
>>> >> taking quite a long time. I've found that when I restore one of the
>>> >> subsites,
>>> >> I have the same problem if that subsite had children. It seems that
>>> >> although
>>> >> I am backing up subsites, I'm not restoring them.
>>> >>
>>> >> Does anyone know if this is due to the size of the sites, or maybe
>>> >> the
>>> >> amount of time necessary to fully restore the site chain.
>>> >>
>>> >> Thanks
>>>
>>>
>>>
>
>