One option, if you are on a filesystem supporting extents (macOS's apfs and Linux's btrfs only, currently, with xfs and bcachefs support on the horizon): do a copy with reflinks (cp -c on macOS, cp --reflink=auto elsewhere). That should be super fast since all it does is point to existing data and duplicate the metadata.
Then, you can do an operation that collapses the WAL log like `sqlite3 copiedfile.sqlite3 .schema` and that should normally fail if the WAL log was copied at an inopportune time; in that case just try again. This way you can make space-efficient copies of the db on the same disk, and you can copy them to a safe location at your leisure. Keep a few copies around and you have pretty granular snapshots. Wout. On Wed, Feb 27, 2019 at 6:03 PM Simon Slavin <slav...@bigfraud.org> wrote: > On 27 Feb 2019, at 4:16pm, Richard Hipp <d...@sqlite.org> wrote: > > > On 2/27/19, Stephen Chrzanowski <pontia...@gmail.com> wrote: > >> Does write blocking still come into play when using "vaccum into", > > > > The VACUUM INTO command is a reader. So (in WAL mode) some other > > process can continue writing while the VACUUM INTO is running. > > The advantage is that a write from another thread doesn't force a restart > in VACUUM. So the VACUUM process may cause a short delay in the writing > process, but the VACUUM process completes in one operation and then the > database is free until the next backup. > > WAL mode seems to be the right mode for you, unless you have limited disk > space for the journal file. > > Which is best for you depends on the frequency of your reads, writes and > backups, and on how fast your storage medium is. It's not something which > can be usefully predicted for 'average use on average hardware'. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
