What a great piece of software this Plone

Hi folks,

I really feel I need to congratulate the Plone community for all their effort over the years in creating what I think is a real jewel of the open source community. After a week of messing about with it, I can really say that Plone is what I have been looking for my Intranet for a while (why didn't I come across it before?).

One of the biggest concerns I had was backup strategy and portability of the database. Well, it turns out that this is really a no brainer although I struggled to get this info out of the documentation, so I had to trial and error.

This is what I did:
a) I installed the same version of Plone on two separate machines.
b) I created exactly the same site on both.
c) I populated the site with documents and pages on one site (machine 1)
d) I ensured that the Plone instances on both servers were down
e) I copied the "filestorage" and "blobstorage" folders from machine 1 to machine 2 into the respective "var" folder
g) I fired up the Plone instance on machine 2 and voila! It is a specular copy of machine 1. It couldn't be simpler ...

This makes me wonder why would one bother using the Plone internal backup mechanism when as long as you regularly backup our var folder, you are fine. I guess the advantage is that when you have a huge database, you don't want to have several daily copies of the var folders which would use huge amounts of space? I guess the internal backup process uses a progressive backup mechanism?

Also, I am assuming that this approach only works when the tow machines have the same version of Plone. You would not be able to use this approach between different versions as I guess the database structure may change between versions?

Anyway, I thought I would share my experience so that if other run into Plone and have the same concerns I had at the start, this may help them address their concerns.


PS. What I forgot to say was that machine 1 is 32 bit while machine 2 is 64 bit. I guess that doesn't make a difference as I'm not moving binaries and libraries between the two machines ...

1 Like

There is a script (I think its name is repozo) which allows for incremental backups.

It is also used to upgrade Plone: you fist copy (as you did for backup); then you run a migration (which ideally does everything needed to make the database fit for the newer Plone version).

You want to pack your db occasionally for performance reasons. If you just backup your data.fs and don't use repozo you lose history.

Consider your step "d":

By shutting down the origin machine, you ensured that the filestorage and blobstorage were synchronized and that all transactions were complete. If you run a backup on a live server -- without stopping plone -- you can't ensure those conditions. The internal backup mechanism does this without a need for a shutdown.

A bit more detail: https://docs.plone.org/manage/deploying/backup.html#objects-in-motion

Not sure about the more recent ZODB versions, but previous versions ensured transaction atomicity at all times: you could safely copy the FileStorage at (almost) any time -- without the need for a shutdown -- with only a single exception: a very short period during the packing process. I assume this still holds.

1 Like

Thankx for sharing this knownledge.