BUG? Backup BETA vmail more than 2GB

i lost email 3GB because the backup not working
with capacity 3GB from total 7 GB
i do full Backup compressed using backup BETA


(this is test account actually, i fill the email about 3GB to  test - text email with some jpg attachment, to simulate normal email activity)


after backup the file size at full backup manual folder file size about 1.7GB


then i remove the real account
then i restore it using backup BETA-->restore


it only restore 256MB and some trouble in roundcube mail with PLAIN AUTH error
then i fix it with change password
after that, i login to my mail box...


viola... no inbox only sent and spam folder.
email restored 256 MB only w/o inbox

This a good reason for manual backups. I use rsync to backup /var/vmail to another server offsite, but you could use it to backup mail locally to the same disk in another location.

This a good reason for manual backups. I use rsync to backup /var/vmail to another server offsite, but you could use it to backup mail locally to the same disk in another location.

manual backup?


you mean backup3 beta with manual action


or backup that have many option (the other backup) ?

manual backup = SCP or rsync (nothing to do with the web-based control panel).

manual backup = SCP or rsync (nothing to do with the web-based control panel).

it can restore the /vmail without changing password ?

Sure, you can do whatever you want "behind its back". The /var/vmail directory is owned by vmail:mail, so you just recursively set those permissions if you need to.

Sure, you can do whatever you want "behind its back". The /var/vmail directory is owned by vmail:mail, so you just recursively set those permissions if you need to.

just need to zip /vmail then that include all info.. user login password and entire email ?

You don't need to know any user's login info -- just run the operation and reverse it back if you have have a failure or data loss. E-mails are just atomic files owned by vmail:mail -- you don't need to authenticate as the user to read them or rsync them offsite. You can gzip/compress in transit and also at rest on the target drive if you need it be smaller. I have enough disk space on the target to not need compression.

You don't need to know any user's login info -- just run the operation and reverse it back if you have have a failure or data loss. E-mails are just atomic files owned by vmail:mail -- you don't need to authenticate as the user to read them or rsync them offsite. You can gzip/compress in transit and also at rest on the target drive if you need it be smaller. I have enough disk space on the target to not need compression.

sorry im not that pro
but... in other word


i just can ZIP (or tar ) the /var/vmail
and the zip (archive) file can be unzip/untar (extracted) any time...
with condition to chown the owner back for each client email parent folder?

Yes, that sounds right. /var/vmail is Just a Bunch of Files (JBF) -- you can do whatever you want with them.

Yes, that sounds right. /var/vmail is Just a Bunch of Files (JBF) -- you can do whatever you want with them.

omg... just like that?
i was thought i need to backup some vmail db or something....


overall
it just folder

all i need only copy the parent client's folder

You should also backup these DB for a more comprehensive backup of all client info and settings: oauthv2, root_cwp, postfix, postfix_policyd, roundcube

You should also backup these DB for a more comprehensive backup of all client info and settings: oauthv2, root_cwp, postfix, postfix_policyd, roundcube

and that mean... do manually what should cwp does i will test it and take alook inside the sql

Depends on if you trust the machine -- or your own manual backups more. I'm telling you what I do! Those DB don't change very often (roundcube the most), so if you just dump them (or dump all DB) to a backup every 6 mo or so, you're fairly safe.