# Backing up and restoring a single database

**URL:** <https://forums.percona.com/t/backing-up-and-restoring-a-single-database/2682>\
**Category:** Percona XtraBackup\
**Created:** [May 14, 2013, 12:24pm UTC](https://forums.percona.com/t/backing-up-and-restoring-a-single-database/2682 "2013-05-14T12:24:37Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sp3ctre](https://avatars.discourse-cdn.com/v4/letter/s/dbc845/32.png) [@sp3ctre](https://forums.percona.com/u/sp3ctre)\
**Post date:** [May 14, 2013, 12:24pm UTC](https://forums.percona.com/t/backing-up-and-restoring-a-single-database/2682/1 "2013-05-14T12:24:37Z")

</div>

Hi,

I am a new user to xtrabackup. I have a WHM server and was worried about the integrity of backups in the nightly routine. My DB is approx 1GB so getting a little big for mysqldump and I was wondering if xtrabackup would be better.

I have tried a round-trip and it seems to work but I wanted to check if what I am doing it correct. Here goes…

1. Backup using --database and --include options to take just the one DB (all I want, for now)
2. Run --apply-log to the backup to make it ready for restore (I think)

When I want to restore :

1. Copy the contents of the backup folder (the one with the ibd files in it) to the equiv location in the mysql data directory
2. Bounce MySQL (is that the quickest way, other than discarding and importing each tablespace?)

Like I said, I tested and it worked, but I am not 100% sure if it is the best way, so would love some advice is someone has the time.

Thanks in advance,

Jim

---

<div class="post-metadata">

**Author:** ![miguelangelnieto](https://avatars.discourse-cdn.com/v4/letter/m/b9e5f3/32.png) [@miguelangelnieto](https://forums.percona.com/u/miguelangelnieto)\
**Post date:** [May 16, 2013, 5:37am UTC](https://forums.percona.com/t/backing-up-and-restoring-a-single-database/2682/2 "2013-05-16T05:37:45Z")

</div>

Hello Sp3ctre,

To take a backup of a single database you just need to use --include. --databases has no effect for InnoDB files. For example, to backup only the “test” database you can do the following:

innobackupex --include=“^test.” /tmp/

This kind of backups are called “partial backups” and the restore process is more complicated. First before taking the backup you need to have innodb\_file\_per\_table enabled.

During the preparation stage you need to use --export --apply-log. That will create .exp files that will allow you to recover tables one by one. Then you will need to import tables one by one following this procedure:

[url][Percona XtraBackup](http://www.percona.com/doc/percona-xtrabackup/innobackupex/importing_exporting_tables_ibk.html#importing-tables%5B/url%5D)

You cannot just move the backup to the datadir of mysql if you are backing up a single database, because the shared tablespace (ibdata) contains information from all the InnoDB tables. If you restore a partial backup without following the restore procedure of that link you can lose the access to the access to all other databases.

---

<div class="post-metadata">

**Author:** ![sp3ctre](https://avatars.discourse-cdn.com/v4/letter/s/dbc845/32.png) [@sp3ctre](https://forums.percona.com/u/sp3ctre)\
**Post date:** [May 16, 2013, 5:57am UTC](https://forums.percona.com/t/backing-up-and-restoring-a-single-database/2682/3 "2013-05-16T05:57:50Z")

</div>

Thanks for that, it makes sense. I’m not sure I feel that comfortable backing up a single big DB that way though, having to go through that process for every table on restore. The database I have in mind is \<2GB and I have been looking at msqldump --single-transaction to handle getting a valid backup from it. Am I correct in thinking this is probably the most straight forward way of doing it and that xtrabackup is maybe a better option if I were to be backing up all the DB’s on a server?

---

<div class="post-metadata">

**Author:** ![scott.nemes](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/scott.nemes/32/5_2.png) [@scott.nemes](https://forums.percona.com/u/scott.nemes)\
**Post date:** [May 16, 2013, 9:47am UTC](https://forums.percona.com/t/backing-up-and-restoring-a-single-database/2682/4 "2013-05-16T09:47:31Z")

</div>

mysqldump should be fine on a database that small. With --single-transaction and all InnoDB tables, you should be able to get a consistent backup with minimal impact on the server. It is generally a good idea to have a logical type backup to supplement your binary backups anyway. The main downside to a logical backup like mysqldump is that the restore time will be longer in most cases, however with only a 2GB database that should not be too big of an issue as long as the server has decent I/O capacity.

Another possible option would be to setup a slave server that contains (and replicates) only the database you want to backup, and then just use Xtrabackup to backup that slave.

---

<div class="post-metadata">

**Author:** ![sp3ctre](https://avatars.discourse-cdn.com/v4/letter/s/dbc845/32.png) [@sp3ctre](https://forums.percona.com/u/sp3ctre)\
**Post date:** [May 16, 2013, 10:15am UTC](https://forums.percona.com/t/backing-up-and-restoring-a-single-database/2682/5 "2013-05-16T10:15:09Z")

</div>

Hi Scott,

Thanks, that makes a lot of sense. I think for what I need at the moment mysqldump is what I need, but I am keen to test and try out xtrabackup as you suggest as my needs will no doubt grow over time and I see xtrabackup is quite powerful. I think I’ll use mysqldump on my production box for now and setup xtrabackup on a development machine just so I don’t accidentally trash it 🙂

Thanks again

---

<div class="post-metadata">

**Author:** ![CESAR\_MURILO\_DA\_SILV](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/cesar_murilo_da_silv/32/1248_2.png) [@CESAR\_MURILO\_DA\_SILV](https://forums.percona.com/u/CESAR_MURILO_DA_SILV)\
**Post date:** [November 25, 2019, 8:29am UTC](https://forums.percona.com/t/backing-up-and-restoring-a-single-database/2682/6 "2019-11-25T08:29:09Z")

</div>

> [@miguelangelnieto;10166](#):
>
> Hello Sp3ctre,
> 
> To take a backup of a single database you just need to use --include. --databases has no effect for InnoDB files. For example, to backup only the “test” database you can do the following:
> 
> innobackupex --include=“^test.” /tmp/
> 
> This kind of backups are called “partial backups” and the restore process is more complicated. First before taking the backup you need to have innodb\_file\_per\_table enabled.
> 
> During the preparation stage you need to use --export --apply-log. That will create .exp files that will allow you to recover tables one by one. Then you will need to import tables one by one following this procedure:
> 
> [http://www.percona.com/doc/percona-x…porting-tables](http://www.percona.com/doc/percona-xtrabackup/innobackupex/importing_exporting_tables_ibk.html#importing-tables)
> 
> You cannot just move the backup to the datadir of mysql if you are backing up a single database, because the shared tablespace (ibdata) contains information from all the InnoDB tables. If you restore a partial backup without following the restore procedure of that link you can lose the access to the access to all other databases.

To help, to the point, the link mentioned is from the documentation in general (I believe that because I see a partial link name ‘…porting-tables’ this page has been removed and directed to the general documentation), the specific link for restoring partial backups is this:

[https://www.percona.com/doc/percona-…ables\_ibk.html](https://www.percona.com/doc/percona-xtrabackup/2.3/innobackupex/restoring_individual_tables_ibk.html)

Important to read before: [https://www.percona.com/doc/percona-…obackupex.html](https://www.percona.com/doc/percona-xtrabackup/2.3/innobackupex/partial_backups_innobackupex.html)
