On 09/02/16 15:31, Mickey Feldman wrote:
The wiki is now about 10 GB. It does compress to about 1 GB. Although
text pages are saved as their differences,
Not exactly. Only if you run a maintenance script, which you probably
as far as I know new versions of images are saved in
I want to do a daily off-site backup. This wiki is on
a shared virtual
host without command line access, thus no ability to use rsync over ssh,
which would allow only the changes to be moved. An entire image of the
system needs to be saved so that it can be restored fairly painlessly. I
want to shrink this as much as possible, since I am already running into
problems with the archiving of the system on the host due to size. For
example, I have had to compress each branch of the images folder
individually - gzipping it into a single archive fails, despite the
hosting company having bumped timeouts and memory allowances.
Moving to a host with complete command line access might be a solution,
but currently the hosting company deals with security issues (beyond
allowing only authorized users to log in of course). If we go to
something like rackspace, then security becomes our problem, and I don't
pretend to have sufficient expertise in that.
Suggestions and alternatives welcome.
If you are at the point of wanting to remove old revisions in order to
have a small backup size, you could as well filter it to only include
Seems like the wrong solution, though. I don't think the size of your
old revisions will be significative in the whole backup size.
I would check if rsync binary is installed, even if you don't have
command line access. You could have a cron (or launch from a web page…
if there's no other way) the rsync that copies the changes to the other
Just note that should your main site be compromised, you do not want
your backup to be deleted through that path. Not that different from
ensuring that if your files were corrupted (on purpose?) your backup
won't be copying those changes before you notice, though.