{"id":5008,"date":"2020-12-03T18:41:12","date_gmt":"2020-12-03T21:41:12","guid":{"rendered":"https:\/\/blog.clusterweb.com.br\/?p=5008"},"modified":"2020-12-03T18:41:12","modified_gmt":"2020-12-03T21:41:12","slug":"migrating-opensource-zimbra-8-6-0-on-centos-6-8-to-zimbra-8-7-1-on-centos-7-safely-and-with-no-downtime","status":"publish","type":"post","link":"https:\/\/blog.clusterweb.com.br\/?p=5008","title":{"rendered":"Migrating opensource Zimbra 8.6.0 on Centos 6.8 to Zimbra 8.7.1 on Centos 7 safely and with no downtime"},"content":{"rendered":"

A bit of history for the context<\/h3>\n

After running a Zimbra mail server in\u00a0a 500Gb Virtual Machine, for about 4 years, the server started feeling\u00a0a bit crowded and with \u00a0#df -h reporting less than 50Gb of space left, it was time to move to a larger machine.<\/p>\n

The version I was (and still am) running is the open source version, there are no migration tools available as part of the package, although you can find plenty of tutorials on the web forums about how to rsync stuff between the old and the new server. I was not comfortable with that. For starters, there would be down time involved, but apart from that I would have to rsync between two identical servers, meaning that the new server would still need to be zimbra 8.6 and running on an identical Centos 6 machine.<\/p>\n

There was also the fact that some time ago, the server did a very bad\u00a0shutdown (due to a power failure), and the database had been corrupted, and every so often a problem or two would crop up in the logs. This became very evident when an upgrade to 8.7.1 failed miserably, and the only thing that saved the day was the backup from the previous night ! I was afraid that most likely, an rsync migration would also\u00a0transfer the problematic data, and that it would be back to haunt me down the road.<\/p>\n

Since I was going to have to go through all the aches and \u00a0pains of \u00a0a server migration \u00a0I wanted to end up not only with more space, \u00a0but also to move to a newer O.S., and a newer release, so rsync was out of the question.<\/p>\n

<\/p>\n

zmmailbox and cli to the rescue<\/h3>\n

If you have spent any time at all administering a Zimbra mail server, you are definitely familiar with the\u00a0zmprov\u00a0command. You might have used it to reset a forgotten admin password, or to list all the accounts using a forwarding address or to really do any other thing you could do from within the web interface ! You might be a bit less familiar with zmmailbox.<\/p>\n

Like zmprov, zmmailbox is also a very powerful command, and can be used to do something as thrivial as creating a mail folder, but it can also export whole mailboxes in \u201ctgz\u201d format, including any folder structure the user might have \u2026. AWESOME !! The only downside is that each mailbox needs to be exported separately, and you cannot use \u201c*\u201d or any wildcards. We are running on Linux however, so we can write \u00a0bash scripts to do all the heavy lifting for us :).<\/p>\n

Preparing the new server<\/h3>\n

You can follow my guide about how to install Zimbra 8.7.1 on Centos 7. If you already know how to do it, just go ahead and install the new server. Basically you will need to install a server with the same settings you used for your old server, but with a different I.P. Address. Remember to setup named, and the zone file accordingly, along with the \/etc\/hosts file. You do not need to create all the domains inside the server. Just create your main one, we will import the others automatically. Remember that if you intend to install a \u201cletsencrypt\u201d certificate later on, your server name needs to be the same as your http:\/\/webmail name. Normally I like to use webmail.domain.com<\/p>\n

Switching over to the new server<\/h3>\n

In order to have virtually zero down time, we will proceed as follows :-<\/p>\n

    \n
  1. Set the DNS TTL Entries pertinent to the mail server to the shortest possible time (Ideally this is done a day before to make sure the ttl propagates accordinly)<\/li>\n
  2. Prepare a fully working new server<\/li>\n
  3. Import all existing domains from the old server.<\/li>\n
  4. Import all existing accounts, passwords, distribution lists, and aliases from the old server<\/li>\n
  5. Move all DNS Pointers and firewall port forwards to the new server (or leave the DNS Pointers as they are, and simply swap the servers\u2019 I.P. Addresses old to new, and new to old. (More about this later)<\/li>\n
  6. Make sure that new mail is arriving \u00a0on the new server.<\/li>\n
  7. Make sure users are able to connect and use the new server.<\/li>\n
  8. Export Mailbox data from the old server, and import it to the new while the new server is running<\/li>\n<\/ol>\n

    Before you go any further \u2026<\/h3>\n

    Most of the commands executed during export, and more importantly during import, may take hours. These should be run directly from \u00a0a console session. If you have absolutely no choice then to run the commands remotely, make sure you use the \u201cscreen\u201d command, so that if the connection gets interrupted, you can connect back to your screen, without disrupting any running scripts<\/strong><\/p>\n

    The export part<\/h3>\n

    Before we begin the export part, we need \u00a0to make sure we have enough storage space, which can be accessed from both \u201cold\u201d and \u201cnew\u201d servers. The old server did not have any space left but the new server had vitually 1Tb of free space. The way to go, in my case was to remote mount an NFS share from the new server, on the old server and use it as the intermediate storage. Other ways include external usb drives, a network attached storage etc. The choice is really up to you. The steps that follow are generic, and assume the intermediate storage is located at\u00a0\/migration\/zimbra.\u00a0<\/strong>If your path is different you will need to modify the scripts accordingly. To keep things organised, we will create separate folders for all the different migration files. Also make sure the path is readable \/ writable to Zimbra user. In this case I would recommend<\/p>\n

    # chmod 777 \/migration\r\n# chmod 777 \/migration\/zimbra\r\n# chown zimbra:zimbra \/migration\r\n# chown zimbra:zimbra \/migration\/zimbra<\/pre>\n
    Step 1. Export all domains<\/h4>\n
    # su - zimbra\r\n# cd \/migration\/zimbra\r\n# mkdir domains\r\n# cd domains\r\n# zmprov gad | tee -a domains.txt<\/pre>\n
    The command should last only a few seconds, depending on the number of domains on the server. A quick cat domains.txt will show us the available domains<\/p>\n
    # cat domains.txt\r\ndomain1.com\r\ndomain2.com<\/pre>\n
    Step 2. Export all\u00a0accounts<\/h4>\n
    Go back to \/migration\/zimbra<\/p>\n
    Create a new directory called accounts and export the admin accounts<\/p>\n
    # cd \/migration\/zimbra\r\n# mkdir accounts\r\n# cd accounts\r\n# zmprov gaaa | tee -a admins.txt<\/pre>\n
    Again a quick \u201ccat admins.txt\u201d should list the domain admins, the same ones you see during execution of the \u201ctee \u2013 a\u201d command.<\/p>\n
    Next we export all the users<\/p>\n
    # zmprov -l gaa | tee -a users.txt<\/pre>\n
    Step 3. Export all\u00a0account details<\/strong><\/h4>\n
    Go back to \/migration\/zimbra<\/p>\n
    Create a new directory called account_details, and export all account details\u00a0from Zimbra.<\/p>\n
    # cd \/migration\/zimbra\r\n# mkdir account_details\r\n# cd account_details\r\n# for user in `cat ..\/accounts\/users.txt`; do zmprov ga $user \u00a0| grep -i Name: | tee -a $user.txt ; done\r\n\r\n<\/pre>\n
    Step 4. Export all\u00a0account\u00a0passwords<\/strong><\/h4>\n
    Go back to \/migration\/zimbra<\/p>\n
    Create a new directory called passwords, and export all shadow passwords<\/p>\n
    # cd \/migration\/zimbra\r\n# mkdir passwords\r\n# cd passwords\r\n# for user in `cat ..\/accounts\/users.txt`; do zmprov -l ga $user userPassword | grep userPassword: | awk '{ print $2}' | tee -a $user.shadow; done<\/pre>\n
    Step 5. Export all distribution lists<\/strong><\/h4>\n
    Go back to \/migration\/zimbra<\/p>\n
    Create a new directory called distribution_lists, and export all\u00a0distribution lists<\/p>\n
    # cd \/migration\/zimbra\r\n# mkdir distribution_lists\r\n# cd distribution_lists\r\n# zmprov gadl | tee -a distribution_lists.txt\r\n# for list in `cat distributinlist.txt`; do zmprov gdlm $list > $list.txt ;echo \"$list\"; done<\/pre>\n
    Step 6. \u00a0Export all aliases<\/h4>\n
    Go back to \/migration\/zimbra<\/p>\n
    Create a new directory called aliases and export all mail aliases<\/p>\n
    # cd \/migration\/zimbra\r\n# mkdir aliases\r\n# cd aliases\r\n# for user in `cat ..\/accounts\/users.txt`; do zmprov ga \u00a0$user | grep zimbraMailAlias | awk '{print $2}' | tee -a $user.txt ;echo $i ;done\r\n<\/pre>\n
    This process will take some time, depending on the number of accounts. Since most accounts won\u2019t actually have aliases, we will end up with a lot of unnecessary empty text files, which we will delete using \u201cfind . -type f -empty | xargs -n1 rm -v\u201d<\/p>\n
    # find . -type f -empty | xargs -n1 rm -v\r\n<\/pre>\n
    So far we have exported everything from our old server, except the mailboxes themselves and any filters the users might have created. We also have the following backup folder structure :-<\/p>\n
    \"\"<\/p>\n
    Step 7. Restore all domains to the new server<\/h4>\n
    The first step in the restoration process starts by restoring all domains. If you have already created the main domain on the new server, you can delete it from\u00a0\/migration\/zimbra\/domains\/domains.txt<\/em><\/p>\n
    The\u00a0next part assumes that the data we just just exported in the above section is available or copied (in the same directory structure) on the new server. If you have to copy the data, ensure that you issue a\u00a0chown \u00a0-R zimbra:zimbra\u00a0<\/em>in \/migration\/zimbra to make sure, user zimbra has full acess to all the files and directories.<\/p>\n
    Let me also remind you again that any interruption during the the execution of these scripts could result in database corruption, these commands should be run either from a console or via a screen session. You have been warned.<\/strong><\/p>\n
    Let\u2019s begin. Login as zimbra user and issue the following commands :-<\/p>\n
    # cd \/migration\/zimbra\/domains\r\n# for domain in `cat domains.txt `; do zmprov cd $domain zimbraAuthMech zimbra ;echo $domain ;done<\/pre>\n
    A quick visit to https:\/\/youserver-ip:7071 should confirm that the domains have been imported successfully.<\/p>\n
    Step 8. Restore all\u00a0accounts and passwords<\/h4>\n
    Restoring accounts and passwords requires the use of a small script. \u00a0Restoring each account will entail creating the account with a temporary password, and restoring the old password in another step.<\/p>\n
    Go to \/migration\/zimbra<\/p>\n
    create a directory called \u201cscripts\u201d, and cd to it, and open your favourite editor to create a file called restore_accounts.sh<\/p>\n
    # cd \/migration\/zimbra\r\n# mkdir scripts\r\n# cd scripts\r\n# vim restore_accounts.sh\r\n\r\n<\/pre>\n
    Paste this script to your file and save it<\/p>\n
    #!\/bin\/bash\r\nPASSWDS=\"..\/passwords\"\r\nACCOUNT_DETAILS=\"..\/account_details\"\r\nUSERS=\"..\/accounts\/users.txt\"\r\nfor i in `cat $USERS`\r\n do\r\n givenName=$(grep givenName: $ACCOUNT_DETAILS\/$i.txt | cut -d \":\" -f2)\r\n displayName=$(grep displayName: $ACCOUNT_DETAILS\/$i.txt | cut -d \":\" -f2)\r\n shadowpass=$(cat $PASSWDS\/$i.shadow)\r\n zmprov ca $i \"TeMpPa55^()\" cn \"$givenName\" displayName \"$displayName\" givenName \"$givenName\"\r\n zmprov ma $i userPassword \"$shadowpass\"\r\ndone<\/pre>\n
    Make the script executable\u00a0chmod 777 restore_accounts.sh,\u00a0<\/em>and execute it<\/p>\n
    # chmod 777 restore_accounts.sh\r\n# .\/restore_accounts.sh<\/pre>\n
    The user accounts, and their relative passwords are now being imported into the new server. You might get an error every now and again saying :-<\/p>\n
    ERROR: account.ACCOUNT_EXISTS (email address already exists: admin@domain.com, at DN: uid=admin,ou=people,dc=domain,dc=com)<\/pre>\n
    This basically means that the account which is currently being imported already exists. This is true for admin, anti spam and anti virus accounts (you may wish to delete these accounts from\u00a0\/migration\/zimbra\/accounts\/users.txt<\/em>. Also keep in mind that after the script runs, the admin password of the new server will now be the same as the admin password of the old server . The password you have created during the installation will be overwritten\u00a0(unless you delete\u00a0admin@domain.com<\/strong>\u00a0from\u00a0users.txt<\/em>)<\/p>\n
    Step 9. Restore distribution lists<\/h4>\n
    Go to \/migration\/zimbra and execute the following command to re-create the distribution lists<\/p>\n
    for lists in `cat \u00a0distribution_lists\/distribution_lists.txt`; do zmprov cdl distribution_lists\/$lists ; echo \"$lists -- done \" ; done<\/pre>\n
    Next we need to populate the lists, using a very short bash script<\/p>\n
    Go to \/migration\/zimbra\/distribution_lists and copy and paste the script below to restore_dist_lists.sh<\/p>\n
    # cd \/migration\/zimbra\/distribution_lists\r\n# vim restore_dist_lists.sh<\/pre>\n
    paste the following script, save and make it executable, and run it.<\/p>\n
    #!\/bin\/bash\r\nfor list in `cat distribution_lists.txt`\r\ndo\r\n    for mbmr in `grep -v '#' .\/$list.txt | grep '@'`\r\n    do\r\n        zmprov adlm $list $mbmr\r\n        echo \" $mbmr has been added to $list\"\r\n    done\r\ndone<\/pre>\n
    <\/h3>\n
    # chmod 777 restore_dist_lists.sh\r\n# .\/restore_dist_lists.sh<\/pre>\n
    You will see members being added to the various distribution lists, as the script goes thru the lists. Depending on the number of distribution lists, and the number of members in each list, this script could take a few minutes to finish<\/p>\n
    Step 10. Restore all aliases<\/h3>\n
    Next we restore the user aliases.<\/p>\n
    You guessed it go to\u00a0\/migration\/zimbra\/aliases<\/p>\n
    create a new script called restore_aliases.sh paste the script below into it, and make it executable<\/p>\n
    # cd \/migration\/zimbra\/aliases\r\n# vim restore_aliases.sh<\/pre>\n
    #!\/bin\/bash\r\necho \"Processing User accounts\"\r\nfor user in `cat ..\/accounts\/users.txt`\r\ndo\r\n    echo $user\r\n    if [ -f \".\/$user.txt\" ]; then\r\n        for alias in `grep '@' .\/$user.txt`\r\n        do\r\n            zmprov aaa $user $alias\r\n            echo \"$user ALIAS $alias - Restored\"\r\n        done\r\n     fi\r\ndone\r\n\r\necho \"Processing Admin accounts\"\r\nfor user in `cat ..\/accounts\/admins.txt`\r\ndo\r\n    echo $user\r\n    if [ -f \".\/$user.txt\" ]; then\r\n        for alias in `grep '@' .\/$user.txt`\r\n        do\r\n            zmprov aaa $user $alias\r\n            echo \"$user ALIAS $alias - Restored\"\r\n        done\r\n    fi\r\ndone<\/pre>\n
    # chmod 777 restore_aliases.sh\r\n# .\/restore_aliases.sh<\/pre>\n
    Step 11. Bring the new server online, and take the old server offline<\/h4>\n
    At this point, we have migrated all the user accounts, their passwords, all the distribution lists, and account aliases. For all intents and purposes, we have a fully working server.<\/p>\n
    For good measure, let\u2019s restart zimbra services<\/p>\n
    # zmcontrol restart<\/pre>\n
    Wait for the services to restart, and issue a zmcontrol status<\/p>\n
    #zmcontrol status\r\nHost domain.com\r\n amavis Running\r\n antispam Running\r\n antivirus Running\r\n ldap Running\r\n logger Running\r\n mailbox Running\r\n memcached Running\r\n mta Running\r\n opendkim Running\r\n proxy Running\r\n service webapp Running\r\n snmp Running\r\n spell Running\r\n stats Running\r\n zimbra webapp Running\r\n zimbraAdmin webapp Running\r\n zimlet webapp Running\r\n zmconfigd Running\r\n\r\n<\/pre>\n
    Login to the web interface, and check that the number of accounts on the new server is the same as the number of accounts on the old server. There could be a minor discrepancy, if you have used a different domain name when you created the new server, this is due to the spam, galsync, and antivirus accounts which will lead to the number of accounts on the new server to be slightly higher than on the old one.<\/p>\n
    Once happy with what you see, login using a normal user account, and check to see if you can send emails to your domain, using the test server. Since it is running its own DNS server, and it believes it is the mail server for your domain.com, emails to any account on the server should be delivered immediately.<\/p>\n
    Check \/var\/log\/zimbra.log for any anomalies.<\/p>\n
    If all seems well, it is time to take server live.<\/p>\n
    There are two ways to do this.<\/p>\n
      \n
    • Change all DNS records and port forwarding on your firewall to the new server I.P<\/li>\n
    • Wait for the DNS records to propagate before continuing with the migration<\/li>\n<\/ul>\n
      or<\/p>\n
        \n
      • Disconnect the new server from the network<\/li>\n
      • Change its I.P. Address to that of the old server<\/li>\n
      • Modify its\u00a0\/etc\/hosts<\/em>,\u00a0\/etc\/named.conf\u00a0<\/em>and\u00a0\/var\/your_zone_file<\/strong><\/em>\u00a0<\/strong>\u00a0accordingly<\/li>\n
      • Restart the zimbra services (this is necessary if you mess around with DNS records)<\/li>\n
      • Make sure the server is still able to send \/ receive emails to and form its own domain<\/li>\n
      • Disconnect the Old mail server from the Network<\/li>\n
      • Connect the new server to the network (which will now be live)<\/li>\n
      • Change the IP address of the Old server to an unused I.P. Address<\/li>\n
      • Modify its\u00a0\/etc\/hosts<\/em>,\u00a0\/etc\/named.conf\u00a0<\/em>and\u00a0\/var\/your_zone_file<\/strong><\/em>\u00a0<\/strong>\u00a0accordingly<\/li>\n
      • Restart zimbra services<\/li>\n
      • Connect it back to the network, to continue the migration of the mailbox data<\/li>\n<\/ul>\n
        The second method, seems more complicated, but it will guarantee ZERO downtime. Believe it or not, it could be the fastest method to switch over to the new server.<\/p>\n
        Once the switch over is complete, any users logging in to the server using IMAP or Webmail will be greeted with an empty mailbox, but any new emails arriving to the domain, will be delivered to the new server.<\/p>\n
        In the final few steps we will export the mailbox data from the old server, and import it to the new server.<\/p>\n
        Step 12.\u00a0Migrating mailbox data<\/h4>\n
        The next process will be the most time consuming of all the processes. Depending on the amount of data, exporting the data could take as long as a day if not more. Data import will take just as long.<\/p>\n
        Now that our users can login to the new server and send and receive emails, the pressure is a bit lower. Also if a very important email needs to be accessed, this can be done via the web interface of the old server, using https:\/\/old-server-i.p.<\/p>\n
        Let\u2019s start the data export.<\/p>\n
        Login to the old server, via console or via a \u201cScreen\u201d session. I am assuming that the backup repository we were using in \/migration\/zimbra is mounted again on the \u201cold\u201d server using\u00a0the same path<\/p>\n
        Login as Zimbra user and goto \/migration\/zimbra<\/p>\n
        # su - zimbra\r\n# cd \/migration\/zimbra\u00a0\r\n# mkdir mailbox_data\r\n# cd mailbox_data\r\n# for user in `cat ..\/accounts\/users.txt`; do\u00a0echo \"Exporting mailbox $user\" ; <\/span>zmmailbox -z -m $user getRestURL '\/?fmt=tgz' > .\/$user.tgz ; done\r\n\r\n<\/pre>\n
        You will start seeing mailboxes being exported. This is going to take a while, so you might go endeavor in other projects.<\/p>\n
        In the event that any mailboxes report errors during export, make a note of the problematic accounts, and try to re export them later, by creating a text file :<\/p>\n
        \/migration\/zimbra\/accounts\/problematic_accounts.txt\u00a0<\/em><\/p>\n
        and running the following command. The format of the file needs to be exactly like the format inside\u00a0\/migration\/zimbra\/accounts\/users.txt.\u00a0<\/em>Use it as reference.<\/p>\n
        # for user in `cat ..\/accounts\/problematic_accounts.txt`; do\u00a0echo \"Exporting mailbox $user\" ; <\/span>zmmailbox -z -m $user getRestURL '\/?fmt=tgz' > .\/$user.tgz ; done<\/pre>\n
        Once the mailbox migration complete, let\u2019s also export any user filter settings. We need a bash script for this.<\/p>\n
        Create a new directory called filters, create a file called export_filters.sh and paste the script below into it.<\/p>\n
        # mkdir \/migration\/zimbra\/filters\r\n# cd \/migration\/zimbra\/filters\r\n# vim export_filters.sh\r\n# chmod 777 export_filters.sh<\/pre>\n
        #!\/bin\/bash\r\nmkdir tmp\r\nset -x\r\nclear\r\nfor user in `cat ..\/accounts\/users.txt`; \r\ndo\r\n    filter=`zmprov ga $user zimbraMailSieveScript > .\/tmp\/$user`\r\n    sed -i -e \"1d\" .\/tmp\/$user\r\n    sed 's\/zimbraMailSieveScript: \/\/g' .\/tmp\/$user > .\/$user;\r\n    rm .\/tmp\/$user\r\n    echo \"Export filter for $user\"\r\ndone\r\n\\rm -rf tmp\r\n<\/pre>\n
        Mount, move or copy \/accounts\/zmigrate to the new server, and go to the\u00a0\/migration\/zimbra\/mailbox_data<\/em>\u00a0directory<\/p>\n
        # cd \/migration\/zimbra\/mailbox_data\r\n# for mailbox in `cat ..\/accounts\/users.txt`; do zmmailbox -z -m $mailbox postRestURL \"\/?fmt=tgz&resolve=skip\" .\/$mailbox.tgz ; echo \"$mailbox - done \"; done\r\n<\/pre>\n
        This process will also take quite a while to complete, the users may use the server freely during the import. When their turn arrives, they will start seeing their mailbox starting to get populated with the emails they left behind on the old server.<\/p>\n
        If you get any errors, you can re-export, and re-import the problematic accounts by manipulating \/migration\/zimbra\/accounts\/users.txt accordingly and re-running the export command. If you get any \u201cbroken pipe\u201d type errors it probably means that the tar archive got corrupted during the transfer for some reason or other, and is essentially incomplete.<\/p>\n
        Finally let\u2019s import the user filters. Go to\u00a0\/migration\/zimbra\/filters,\u00a0<\/em>and create a file called import_filters.sh. Paste the script below into it, save and make it executable.<\/p>\n
        # cd \/migration\/zimbra\/filters\r\n# vim import_filters.sh\r\n# chmod 777 import_filters.sh<\/pre>\n
        #!\/bin\/bash\r\nfor filter in .\/*\r\ndo\r\n    if [ \"$filter\" == \".\/import_filters.sh\" ] ; then\r\n        continue;\r\n    fi\r\n\r\n\r\n    if [ \"$filter\" == \".\/export_filters.sh\" ] ; then\r\n        continue;\r\n    fi\r\n\r\n    if [ \"$filter\" == \".\/tmp\" ] ; then\r\n        continue;\r\n    fi\r\n\r\n    Filter_String=`cat \"$filter\"`\r\n    Account=$filter\r\n    zmprov ma $(echo $filter | grep -E -o \"\\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,6}\\b\") zimbraMailSieveScript '$Filter_String'\r\n    echo \"Process filter $Account\"\r\ndone\r\necho \"All filter has been import successfully\"\r\n<\/pre>\n
        Conclusion<\/h4>\n
        That\u2019s it, \u00a0your users should be happy using your newly migrated server. The only thing they will find missing are their account signatures. To date I have not yet found an automated reliable way to copy them automatically. What I did in this case was, made the old server available on a temporary sub-domain (old-webmail.domain.com<\/strong>), so that the users could login in to the old server, and essentially copy and paste their signature to the new server. If you feel extremely generous, you could also do it via the admin interface, but you would have to do the process account by account manually, so it could take some time.<\/p>\n","protected":false},"excerpt":{"rendered":"
        A bit of history for the context After running a Zimbra mail server in\u00a0a 500Gb Virtual Machine, for about 4 years, the server started feeling\u00a0a bit crowded and with \u00a0#df -h reporting less than 50Gb of space left, it was time to move to a larger machine. The version I was (and still am) running […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[477,1082,1,730,725,42,51,495,514,68,74,896],"tags":[621,1516,1085,1519,1513,361,923,1514,1518,921,983,1515,1517],"class_list":["post-5008","post","type-post","status-publish","format-standard","hentry","category-backup-2","category-centos-7-rhel-7","category-viazap","category-clusterweb","category-hospedagem","category-leitura-recomendada","category-linux-linuxrs","category-profissional-de-ti","category-programacao","category-redes-2","category-servidor-de-e-mail","category-zimbra","tag-and","tag-centos-6-8","tag-centos-7","tag-downtime","tag-migrating","tag-no","tag-on","tag-opensource","tag-safely","tag-to","tag-with","tag-zimbra-8","tag-zimbra-8-7-1"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/5008","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5008"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/5008\/revisions"}],"predecessor-version":[{"id":5009,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/5008\/revisions\/5009"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5008"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5008"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5008"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}