# HG changeset patch
# User Laurent Peuch <cortex@worlddomination.be>
# Date 1551194793 -3600
# Node ID c8f69e880e14ae37c3fa3aaebc644b900a691fc1
# Parent  61410626004204ff95f700c4ba5e592b8aca083d
[doc] fix, the cube name was used, it was the instance named that was needed

diff -r 614106260042 -r c8f69e880e14 doc/tutorials/advanced/part04_ui-base.rst
--- a/doc/tutorials/advanced/part04_ui-base.rst	Tue Feb 26 16:25:59 2019 +0100
+++ b/doc/tutorials/advanced/part04_ui-base.rst	Tue Feb 26 16:26:33 2019 +0100
@@ -347,15 +347,15 @@
 
 To generate a dump from the production site: ::
 
-  $ cubicweb-ctl db-dump sytweb
+  $ cubicweb-ctl db-dump sytweb_instance
   pg_dump -Fc --username=syt --no-owner --file /home/syt/etc/cubicweb.d/sytweb/backup/tmpYIN0YI/system sytweb
   -> backup file /home/syt/etc/cubicweb.d/sytweb/backup/sytweb-2010-07-13_10-22-40.tar.gz
 
 I can now get back the dump file (:file:`sytweb-2010-07-13_10-22-40.tar.gz`) to my test
 machine (using `scp` for instance) to restore it and start migration: ::
 
-  $ cubicweb-ctl db-restore sytweb sytweb-2010-07-13_10-22-40.tar.gz
-  $ cubicweb-ctl upgrade sytweb
+  $ cubicweb-ctl db-restore sytweb_instance /path/path/to/sytweb-2010-07-13_10-22-40.tar.gz
+  $ cubicweb-ctl upgrade sytweb_instance
 
 You'll have to answer some questions, as we've seen in `an earlier post`_.