> On Dec 13, 2017, at 3:10 PM, Ben Pfaff <[email protected]> wrote: > > diff --git a/Documentation/ref/ovsdb.7.rst b/Documentation/ref/ovsdb.7.rst > index ddc573a47c94..1f860768df2d 100644 > --- a/Documentation/ref/ovsdb.7.rst > +++ b/Documentation/ref/ovsdb.7.rst > @@ -317,9 +317,14 @@ Another way to make a backup is to use ``ovsdb-client > backup``, which > connects to a running database server and outputs an atomic snapshot of its > schema and content, in the same format used for on-disk databases. > > -To restore from a backup, stop the database server or servers, overwrite > -the database file with the backup (e.g. with ``cp``), and then > -restart the servers. > +Multiple options are also available when the time comes to restore a database > +from a backup. One option is to stop the database server or servers, > overwrite > +the database file with the backup (e.g. with ``cp``), and then restart the > +servers. Another way is to use ``ovsdb-client restore``, which connects to a > +running database server and replaces the data in one of its databases by a > +provided snapshot. Using ``ovsdb-client restore`` has the disadvantage that > +UUIDs of rows in the restored database will differ from those in the > snapshot, > +because the OVSDB protocol does not allow clients to specify row UUIDs.
Do you think it's worth mentioning the cases where it is useful? Does that come later with the clustering change? > diff --git a/ovsdb/ovsdb-client.1.in b/ovsdb/ovsdb-client.1.in > index 2e2df5e5aa7f..30de9c536600 100644 > --- a/ovsdb/ovsdb-client.1.in > +++ b/ovsdb/ovsdb-client.1.in > @@ -33,6 +33,9 @@ ovsdb\-client \- command-line interface to > \fBovsdb-server\fR(1) > \fBovsdb\-client \fR[\fIoptions\fR] > \fBbackup\fI \fR[\fIserver\fR] \fR[\fIdatabase\fR] > \fIsnapshot\fR > .br > +\fBovsdb\-client \fR[\fIoptions\fR] [\fB\-\-force\fR] > +\fBrestore\fI \fR[\fIserver\fR] \fR[\fIdatabase\fR] < \fIsnapshot\fR Same comment as the earlier patches about unnecessary markups. > @@ -41,7 +44,6 @@ ovsdb\-client \- command-line interface to > \fBovsdb-server\fR(1) > \fBovsdb\-client \fR[\fIoptions\fR] \fBmonitor\-cond\fI \fR[\fIserver\fR] > \fR[\fIdatabase\fR] \fIconditions > \fItable\fR [\fIcolumn\fR[\fB,\fIcolumn\fR]...]... > .IP "Testing Commands:" > -.br > \fBovsdb\-client \fR[\fIoptions\fR] \fBlock\fI \fR[\fIserver\fR] \fIlock\fR > .br > \fBovsdb\-client \fR[\fIoptions\fR] \fBsteal\fI \fR[\fIserver\fR] \fIlock\fR > @@ -156,6 +158,30 @@ database is in use. > The output does not include ephemeral columns, which by design do not > survive across restarts of \fBovsdb\-server\fR. > . > +.IP "[\fB\-\-force\fR] \fBrestore\fI \fR[\fIserver\fR] \fR[\fIdatabase\fR] < > \fIsnapshot\fR" Here too. > +Reads \fIsnapshot\fR, which must be in the format used for OVSDB > +standalone and active-backup databases. Then, connects to Do you think it's worth mentioning how you'd get it in that format? > +Normally \fBrestore\fR exits with a failure if \fBsnapshot\fR and the > +server's database have different schemas. In such a case, it is a > +good idea to convert the database to the new schema before restoring, > +e.g. with \fBovsdb\-client convert\fR. Use \fB\-\-force\fR to proceed > +regardless of schema differences even though the restore might fail > +with an error or succeed with surprising results. I love surprises! > diff --git a/ovsdb/ovsdb-client.c b/ovsdb/ovsdb-client.c > index 568c46b84d54..1af19d5dbc28 100644 > --- a/ovsdb/ovsdb-client.c > +++ b/ovsdb/ovsdb-client.c > > > @@ -279,6 +289,8 @@ usage(void) > " dump contents of DATABASE on SERVER to stdout\n" > "\n backup [SERVER] [DATABASE] > DB\n" > " dump database contents in the form of a database file\n" > + "\n [--force] restore [SERVER] [DATABASE] < DB\n" > + " restore database contents from a database file\n" There's obviously some precedent, but the man page uses "snapshot" instead of "DB". It might be nice to use consistent terms--especially since the difference between "DATABASE" and "DB" is not obvious without context--but it's not a big deal. Acked-by: Justin Pettit <[email protected]> --Justin _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
