[Trac] How to move an existing and running trac to a new server

[Kiesel]

Hi!
My new job at the university im at is to move an existing and running trac
to a new server. No one here knows anything about it and as im the new guy,
the decision was that i had to do it.

I set up a working (but empty) trac, but now im not able to import the
existing projects.
Backing up like described here http://trac.edgewall.org/wiki/TracBackup
works fine, but when i try to set up a new environment
(http://trac.edgewall.org/wiki/TracEnvironment) the script ends with an
error and says:
character 0xe28692 of encoding "UTF8" has no equivalent in "WIN1252".

So i tried to change my postgres db encoding to UTF8, but then i can't
import the dump from the old db (I know trac-admin does that in the backup
step) which i need because there are 34 something existing databases and not
for all are the passwords known...
The error during the import says:
encoding WIN1250 does not match server's locale German_Germany.1252

When i try to change it to WIN1250 (in postgres) i need to change my locale
settings accordingly but i dont know to which locale.

Is there a simpler way to move the existing trac or does anybody know how to
solve the encoding problem?

Any help regarding this would really be appreciated.
Thank you very much!

Windows Server 2008
Postgres 8.3
--
View this message in context: http://old.nabble.com/How-to-move-an-existing-and-running-trac-to-a-new-server-tp29294219p29294219.html
Sent from the Trac Users mailing list archive at Nabble.com.

[Josh Godsiff]

I recently had to migrate around 20 Trac projects from one server to
another for work. My process there was just to tarball the whole lot of
them and scp them to a new server. However, that was on Unix (much
better command-line tools than Windows) and using SQLite DBs, so your
mileage may vary.

- Josh
-- www.oxideinteractive.com.au

[Kiesel]

Hi Josh,
didnt you have to do some backup, using the trac-admin script?
Otherwise im wondering how you got the information residing in your sql
databse to the new system.
/David

> I recently had to migrate around 20 Trac projects from one server to
> another for work. My process there was just to tarball the whole lot of
> them and scp them to a new server. However, that was on Unix (much
> better command-line tools than Windows) and using SQLite DBs, so your
> mileage may vary.
>
> - Josh
> -- www.oxideinteractive.com.au
>

> --
> You received this message because you are subscribed to the Google Groups
> "Trac Users" group.
> To post to this group, send email to trac-...@googlegroups.com.
> To unsubscribe from this group, send email to
> trac-users+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/trac-users?hl=en.
>
>
>

--
View this message in context: http://old.nabble.com/How-to-move-an-existing-and-running-trac-to-a-new-server-tp29294219p29334347.html

[Josh Godsiff]

SQLite DBs exist as straight files on the filesystem, and reside within
the project folder - subsequently, tar-balling the directory also grabs
the database.

- Josh

[Cooke, Mark]

> > > I recently had to migrate around 20 Trac projects from one
> > > server to another for work. My process there was just to
> > > tarball the whole lot of them and scp them to a new server.
> > > However, that was on Unix (much better command-line tools
> > > than Windows) and using SQLite DBs, so your mileage may vary.
> > >
> > > - Josh
> > > -- www.oxideinteractive.com.au
> >
> > On 3/8/2010 9:31 PM, Kiesel wrote:
> > Hi Josh,
> > didnt you have to do some backup, using the trac-admin script?
> > Otherwise im wondering how you got the information residing
> > in your sql databse to the new system.
> > /David
> >

> -----Original Message-----
> From: trac-...@googlegroups.com On Behalf Of Josh Godsiff
> Sent: 04 August 2010 02:43
> To: trac-...@googlegroups.com
> Subject: Re: [Trac] How to move an existing and running trac
> to a new server
>

> SQLite DBs exist as straight files on the filesystem, and
> reside within the project folder - subsequently, tar-balling
> the directory also grabs the database.
>
> - Josh
>

I use this idea for our backup strategy. Words of caution follow:

Make sure that trac (and any dB process) is shutdown (I stop the apache
and postgreSQL processes) first to make sure the files are consistent.

Make sure that your restore target is as identical as possible ~ same
version of OS, dB, trac etc installed. There are always potential
issues with just moving data around as the app versions may change how
they handle/store/whatever that data.

For us, the restore target will be a backup image of the VM (low
traffic) so I consider a file level backup easy and quick.

You do need to know where the database files are, Josh indicates the
SQLite ones are in the trac environment tree. I use PostgreSQL but I
set it up and know where the files are (and it is only used for our Trac
dBs)...

~ mark c

P.S. oh, and I do this on Windows which is not as backwards with such
tools these days as some people think...

[Matthew Caron]

> You do need to know where the database files are, Josh indicates the
> SQLite ones are in the trac environment tree. I use PostgreSQL but I
> set it up and know where the files are (and it is only used for our Trac
> dBs)...

You can also just dump the appropriate table out of the database, such
as with pg_dump. For example, this is my nightly DB backup script:

#!/bin/bash

if [ `whoami` != 'postgres' ]; then
echo "Please run this as user postgres";
exit 255;
fi

FILE=$(mktemp /opt/trac/eng/db/postgres.bak.`date +%F`.XXXXXXXXXX)

if [ "$?" -eq "0" ]; then
pg_dump trac > $FILE && lzma $FILE;
fi

(this happens before a full filesystem dump to offline media, so even if
the db is caught in an inconsistent state, we can restore from this..
belt and suspenders and all that).

> P.S. oh, and I do this on Windows which is not as backwards with such
> tools these days as some people think...

Yeah, but why fight with it? I mean, when most Linux distros are free
and (presumably) supported (or at least allowed) in your organization,
why incur the cost of another Windows license and then have to deal with
all the pain and angish of having to set up infrastructure that you get
for free (or, at least, at a very low "<packagemanager> install
<thingy>" cost), it just seems easier to run it on Linux. Heck, most
Linux distros these days are basically turnkey, and picking one over
another ends up coming down a lot to preference.
--
SIXNET - Industrial and Wireless Connectivity
331 Ushers Road, Ballston Lake, NY 12019
Tel: 1.518.877.5173, Fax: 1.518.877.8346
www.sixnet.com