I hate Plesk (Backup Hell)

[fouldragon at aol.com]

Am I the only one who finds Plesk an utter and complete nightmare?  
They seem to ship it with bugs that projects that never escaped "1-Pre 
Alpha" on Freshmeat would be ashamed to!

I administer a reasonably servicable Fedora 4-based server with about 
sixty domains (many of which are just redirect hosting or abandoned 
clients)

It ran Plesk 8.0.0.

I decided it would be good for security reasons to update to the most 
recent PHP and MySQL.

Plesk 8.0 doesn't like MySQL 5 series.

So I have to upgrade that to 8.1.1.

Fine.  After two days of fighting, normality returns.

I've got the system set up to back itself up to an external FTP once a 
week.  It did this with the 'pleskbackup all' command.  This resulted 
in the generation of a ~15-20Gb file.

I don't have 20Gb of space anymore.  And apparently, you can't just 
'pleskbackup all' to a FTP site with that version, despite the claims 
it was supposed to be fixed in 8.1.

For obvious reasons, I have no particular lust to update to 8.2, and 
open yet another Pandora's box (it feels like Pandora meets Deal or No 
Deal)

So fine... I'll write a little shell script to do backups of single 
domains, FTP them over, and delete them. No single domain should be 
over 6Gb.  Seems simple.  (I try to use pleskbackup domains command).

So I test it out on a small domain.  pleskbackup runs fine, but when I 
do 'pleskrestore --create-map' using the resultant file, it dumps a 
stack of errors:

Traceback (most recent call last):
File "/usr/local/psa/admin/share/supervisor/processor.py", line 83, in 
getStatus
return (None, self.realGetStatus())
File "/usr/local/psa/admin/share/supervisor/processor.py", line 413, in 
realGetStatus
info = dump_format.readInfo(fh)
File "/usr/local/psa/admin/lib/python/dump_format.py", line 399, in 
readInfo
xml.sax.parse(fp, i)
File "/usr/lib/python2.4/xml/sax/__init__.py", line 33, in parse
parser.parse(source)
File "/usr/lib/python2.4/xml/sax/expatreader.py", line 107, in parse
xmlreader.IncrementalParser.parse(self, source)
File "/usr/lib/python2.4/xml/sax/xmlreader.py", line 123, in parse
self.feed(buffer)
File "/usr/lib/python2.4/xml/sax/expatreader.py", line 211, in feed
self._err_handler.fatalError(exc)
File "/usr/lib/python2.4/xml/sax/handler.py", line 38, in fatalError
raise exception
SAXParseException: /var/backups/restore/dump-plesk.xml:11:33: not 
well-formed (invalid token)

even 'pleskrestore --info' (tell me why the backup is busted) fails 
similarly (dump-plesk.xml at the end is replaced with <unknown> I 
think.)

Pleskbackup reports no obvious errors, so I can't tell if it's 
pleskbackup making a borked file, or pleskrestore failing to parse a 
valid one.

Of course, googling the errors gets me nowhere except a lot of other 
people complaining that Pleskbackup/Pleskrestore doesn't work well for 
them in many different ways.

You'd think backup and restore are inherently things you test the crap 
out of prior to releasing a package like this.

Has anyone got any thoughts as to what might be wrong?

Alternatively, how else would you solve the problem:

1. I need to backup as completely as possible a Plesk-orchestrated 
server with 20-25Gb of data on it.  This includes email and databases, 
but I can forego logs.  I'd prefer to be able to suck back the Plesk 
configuration rather than have to reassemble it from scratch when 
rebuilt.
2. I have access to storage space via FTP only, and a total of 30G of 
space there.
3. I need a minimal (<10Gb at any one moment) disc-space footprint on 
the running server.
4. It should be reasonably simple to reconstitute in the event of 
calamity.
5. Ideally, it would not drive the load average to 87.

Any thoughts?  Most of the answers I see involve "use pleskbackup all 
and FTP it over in some way", which fails because of part 3.
________________________________________________________________________
Email and AIM finally together. You've gotta check out free AOL Mail! - 
http://mail.aol.com