We’re trying to set up a new copy of our database on a new server, using the our nightly xtrabackup/innobackupex backup. The complicating factor is that our database is quite large: 2.6TB.
So we copy over the gzip’d tarball, and expand it to the full size. Now as I understand, the next steps are to “prepare” it and then “restore” it. It seems that the “restore” step will create another full copy of the database files, in their restored state of course. Having an additional 2.6TB of space just for this temporary step is, as you might imagine, going to be expensive.
My question is simply to sanity-check what we’re doing. Is this right? Is there some way around this?
Thanks,
Chris
Austin, TX
What are you doing for the restore? Using the --copy-back function? If it is a full backup, you can just move the prepared backup to the data directory. That should prevent the need of having two copies. The main caveat there would be that if something goes wrong you would have to re-copy the backup to the server again since you used up the only copy.
Yep, I was doing the --copy-back, per [url]Percona XtraBackup I understood that that ‘restore’ step did something more than straight copying, but I guess not?
Thanks, this is just the thing I was wondering.
After the backup is prepared, the directory contents may be moved or copied to the data directory. The --copy-back function may be smart enough to set the correct ownership and permissions perhaps after it copies them (never actually checked), but that’s the only thing I could see it doing. So if you move or copy the backup manually, just make sure to check the ownership of the files in the data directory to make sure they are still correct (i.e. chown -R mysql:mysql /var/lib/mysql).