• Halloween is coming! To celebrate the occasion, we dusted off a couple of old skins, and even created a brand new one (Pixel).
    To get into the festive spirit, install the Skins extension.
  • The new Python extension is now available. It allows customers to deploy and manage WSGI-based Python applications on their websites directly from Plesk.
  • The Plesk Mobile apps for iOS and Android and the Plesk Mobile Center extension have been deprecated, and are no longer available for new installations. In Plesk Obsidian 18.0.84, the Plesk Mobile Center extension will be removed from servers during the upgrade, and the Plesk Mobile apps will lose their server management features.
  • The Social Login extension has been deprecated and will be removed in Plesk Obsidian 18.0.84. After that, it will no longer be possible to log in to Plesk with a Google, Facebook, GitHub account, or with a passkey. Plesk usernames and passwords, as well as logging in with a WebPros Account, are not affected.

pleskbackup all produces suspicious results

Q

quaeler

Guest
I'm running Plesk 8.1.1 under Fedora Core 6; if i run a pleskbackup from command line like this:
./pleskbackup all outputFileName

then the file outputFileName is of a suspiciously small size. In the concrete example shown below, the outputFileName is less than 4Gigs in size, while the du of just vhosts (not even looking at mail, data from the dbs, and everything else which plesk should be backing up) is 11Gigs. Additionally, a lot of the files in that 11Gigs are already compressed media assets - so not even the greatest proprietary compression techniques would likely be capable of making those 11Gigs less than 4Gigs.

[~]# du -sm /var/www/vhosts
11245 /var/www/vhosts

file generated by pleskbackup all (in bytes):
4128303280 p_armor-01Dec-plesk

So my questions are:
. how do i generate a manifest from the generated output file - so i can see what is actually getting backed up (so i can then back up what's missing ~by hand)?
. am i not specifying "all" correctly and that's why it's missing content?

Thanks for any pointers.

ps. and as far as vhosts containing actual backup-able contents (as opposed to 10 gigs of log files):
[vhosts]# for i in `find . -name "httpdocs" -type d`; do du -sm $i; done
1 ./.skel/0/httpdocs
1056 ./xxx.yyy/httpdocs
244 ./xxx.yyy/subdomains/1/httpdocs
659 ./xxx.yyy/subdomains/2/httpdocs
98 ./xxx.yyy/subdomains/3/httpdocs
1534 ./xxx.yyy/subdomains/4/httpdocs
475 ./aaa.yyy/httpdocs
2075 ./bbb.yyy/httpdocs
1 ./bbb.yyy/subdomains/1/httpdocs
4 ./bbb.yyy/subdomains/2/httpdocs
15 ./bbb.yyy/subdomains/3/httpdocs
877 ./ccc.yyy/httpdocs
19 ./ccc.yyy/subdomains/1/httpdocs
135 ./ccc.yyy/subdomains/2/httpdocs
89 ./ddd.yyy/httpdocs
71 ./eee.yyy/httpdocs
134 ./fff.yyy/httpdocs
106 ./ggg.yyy/httpdocs
62 ./hhh.yyy/httpdocs
496 ./hhh.yyy/subdomains/1/httpdocs
1 ./hhh.yyy/subdomains/2/httpdocs
1770 ./iii.yyy/httpdocs
124 ./jjj.yyy/httpdocs
332 ./kkk.yyy/httpdocs

which sums to ~10377
 
this is resolved.

the problem was that pleskbackup directly or indirectly relies upon using /tmp/ to store intermediary chunks in the process of creating the archive file.

the partition on which my /tmp/ sat did not have enough free space for some of the chunks - causing the backup of those chunks to fail (unfortunately: silently).

moving /tmp/ to a more spacious partition resulted in pleskbackup producing a reasonably sized archive file.
 
Back
Top