Upgrade your ArchiveBox collection to a new version
Note: It’s recommended to only upgrade one major version at a time. e.g. if you’re on
v0.4.14, upgrade to
v0.5.6 next, then
v0.6.3, and finally
v0.7.1 (as 3 separate steps).
You can specify exact versions with pip like so:
pip install archivebox==0.6.3 or with docker
docker pull archivebox/archivebox:0.6.3. Upgrading directly across multiple major versions may work in some cases, but is not recommended for maximum data safety.
✅ Upgrading checklist:
Find the version you want to upgrade to on https://github.com/ArchiveBox/ArchiveBox/releases
Read the release notes carefully for any instructions or extra steps around upgrading for each release you’re skipping or installing
Make a full backup of your
archive/content before upgrading!
gzip -9 < index.sqlite3 > "index.sqlite3.$(date +%s).bak"
Follow the steps below depending on your setup to run
archivebox init(repeating as necessary for each major version if upgrading across multiple major versions)
Confirm the upgrade succeeded and check for any orphan/corrupted snapshots with
💬 Open an issue in our bug tracker if you experience any problems with upgrading/merging/modifying collections.
ℹ️ How it works internally:
The same command is used for initializing a new archive and upgrading an existing one.
archivebox init is indempotent and safely be run multiple times. Running it will ensure your collection is on the latest version and all the files are in their correct locations.
archivebox status can be used to check for orphan/corrupted snapshots or invalid index data.
There are three main areas on disk that ArchiveBox modifies during upgrades:
index.sqlite3contains the SQLite3 DB index that gets upgraded automatically by Django based on the changes in
archive/*/index.jsonthese files are redundant json exports of the data for each Snapshot in
index.sqlite3, these files are overwritten on every
archivebox updaterun or anytime the Snapshot is modified from the GUI or CLI. These files will be lazily updated to the latest schema versions as ArchiveBox accesses them, but are usually not modified in bulk during
archivebox initwhen upgrading.
archive/*the Snapshot output files may be moved or renamed by future upgrades (so far they have remained unchanged since v0.1, but future versions reserve the right to change their locations)
ArchiveBox.conf file is not modified by upgrades and should remain forward-compatible across future versions (even when config options are renamed, we check the old names internally to maintain compatibility).
As of v0.4 and above, ArchiveBox uses the Django migrations system for deterministic, atomic, safe upgrades, so your DB should always be left in a consistent state in the event of a failure or power outage. If you need help fixing a corrupted collection, open an issue using the link above.
Upgrading with Docker Compose ⭐️
Using Docker Compose is recommended because it makes upgrading a breeze! ✨
Pulling and running the latest version automatically upgrades the ArchiveBox collection and all of ArchiveBox’s internal dependencies.
cd ~/archivebox # or wherever your data folder is docker-compose down # stop the currently running archivebox containers docker-compose down # run twice to clear stopped containers docker-compose pull # pull the latest image version from Docker Hub docker-compose up # collection will be automatically upgraded as it starts
Upgrading with plain Docker
Upgrading with plain Docker is similar to the process with Docker Compose, but you have to run
archivebox init manually at the end to finish the process.
docker ps -a -q --filter ancestor=archivebox/archivebox # find any currently running archivebox containers docker kill <image> # stop any currently running archivebox versions docker pull archivebox/archivebox docker run -v $PWD:/data -it archivebox/archivebox init --setup # upgrade the collection to the latest version # restart the archivebox server container if needed docker run -v $PWD:/data -it -p 8000:8000 archivebox/archivebox server 0.0.0.0:8000
Upgrading with a package manager
Package manager releases take a lot of effort to maintain (contributions welcome!) and sometimes lag behind the Docker releases. We make a best effort to have the latest release available through all channels within a reasonable timeframe.
cd ~/archivebox # or wherever your data folder is killall archivebox # stop the currently running archivebox version # upgrade ArchiveBox using the package manager you originally used to install it pip install --upgrade archivebox # or brew upgrade archivebox # or apt install --upgrade archivebox # or with the optional auto-installer script curl -sSL 'https://get.archivebox.io' | sh archivebox init # run init to upgrade the collection to the latest version archivebox update --index-only # optionally force an update of the snapshot index files (normally done lazily, see issue #962 for more info) archivebox status # check that everything succeeded
Merge two or more existing archives
Two or more existing ArchiveBox collection dirs can be merged together by simply combining the contents of
archive/* and re-running
archivebox init to pull the new Snapshots into the index.
Upgrade both old collections to the most recent ArchiveBox version (following instructions above)
pip install --upgrade archivebox # or follow instructions above for upgrading w/ Docker cd /path/to/archivebox1/data archivebox init --setup archivebox status cd /path/to/archivebox2/data archivebox init --setup archivebox status # ... repeat the same for each collection if merging more than two
Create a new empty archivebox collection in a new folder somewhere, this will hold the new merged collection
mkdir /path/to/archivebox_new cd /path/to/archivebox_new archivebox init --setup
Copy everything under
./archive/*in each old collection into the new collection’s
rsync --archive --info=progress2 /path/to/archivebox1/data/archive/ /path/to/archivebox_new/data/archive rsync --archive --info=progress2 /path/to/archivebox2/data/archive/ /path/to/archivebox_new/data/archive # ...repeat the same for each collection if merging more than two
archivebox initin the new merged collection to regenerate the new index
cd /path/to/archivebox_new archivebox init --setup
The new collection should now contain all the entries from the old collections combined
cd /path/to/archivebox_new archivebox status # optionally force an update of the snapshot index files (normally done lazily) archivebox update --index-only
For more information about why Snapshot index files are usually updated lazily, see: https://github.com/ArchiveBox/ArchiveBox/issues/962
Modify the ArchiveBox SQLite3 DB directly
If you need to automate changes to the ArchiveBox DB (for example adding a User from an Ansible script), you can modify the SQLite3 DB directly.
Note, this is often unnecessary for modifying ArchiveBox on a host that doesn’t have the CLI installed, as you can also copy the
index.sqlite3 to a local machine that has it, do the modifications locally, then copy the modified db back into place on the host. (Docker/CLI/GUI/Web ArchiveBox all share the same DB schema/format)
cd ~/archivebox # cd into your archivebox collection dir sqlite3 index.sqlite3 # open the db with sqlite3 shell
Example: Modifying an existing user’s email
UPDATE auth_user SET email = 'someNewEmail@example.com', is_superuser = 1 WHERE username = 'someUsernameHere';
Example: Adding a new user with a hashed password
Note: this is just an example to demonstrate direct database usage. If you are trying to create a user on initial setup, use the
ADMIN_PASSWORD configuration options.
First, generate the hashed password in a Python shell using Django’s
This can be done on any machine with Python 3+, it doesn’t have to have ArchiveBox installed.
pip3 install django==3.1.3 # install the django version used by ArchiveBox python3 # open any python shell with django available, doesn't have to be the archivebox shell
>>> from django.contrib.auth.hashers import make_password >>> make_password('somePasswordHere', 'someSaltHere', 'pbkdf2_sha256') # choose a password and a salt (can be anything 12 chars long) 'pbkdf2_sha256$216000$someSaltHere$styW1Uoy8SHp3zbSwGRp20C9mPjOHVjP9rl5a8/UOVE='
Use the generated hashed password to insert a new User row in the SQLite3 database directly:
cd ~/archivebox # cd into your archivebox collection dir sqlite3 index.sqlite3 # open the db with sqlite3 shell
INSERT INTO "auth_user" ("password", "last_login", "is_superuser", "username", "first_name", "last_name", "email", "is_staff", "is_active", "date_joined") VALUES ('pbkdf2_sha256$216000$someSaltHere$+2beZufc3JUXnmn0tG+2peJEBh7MjxPYmT3YfIFzEl0=', NULL, 0, 'someUsername', '', '', 'someEmail@example.com', 0, 1, '2022-03-22 23:34:02.333042')
Replace the values above with the desired username, email, and password hash from python output^.
Log in using the new generated user to confirm it works https://localhost:8000/admin/login/ user:
Database and filesystem issues are uncommon but do come up from time to time (especially when using networked storage, large archives, or multiple ArchiveBox processes for a single collection).
ℹ️ Generally, these commands can help you resolve most issues:
archivebox init # upgrade the archivebox collection archivebox init --setup # upgrade the archivebox collection and all dependencies archivebox update --index-only # force an upgrade of some of the archivebox index/collection files archivebox server --debug # run the server with more verbose debug log output archivebox shell # access the Python API / Django management shell sqlite3 index.sqlite3 # access the SQLite3 SQL database shell
Don’t be scared by the volume of content here. Almost all of these issues linked below are duplicates or old resolved bugs, but they contain valuable context and troubleshooting steps if you’re trying to figure out the cause of a problem with your setup.
Filesystem doesn’t support FSYNC (e.g. network mounts)
index.sqlite3 file must be stored on a filesystem that supports FSYNC (most local filesystems) in order to ensure SQLite3 database integrity when multiple ArchiveBox processes may be accessing it simultaneously. However, the
./archive folder can be on a NAS or other filesystem that does not support FSYNC.
Database and filesystem contention issues when running multiple ArchiveBox processes
ArchiveBox can sometimes struggle when archiving many links in parallel with multiple ArchiveBox processes trying to write to the database at the same time, leading to errors like this:
Unable to create the django_migrations table (database is locked)
These errors can also be encountered when there are permissions, network, or filesystem issues preventing writes to the
Database migrations errors or upgrade issues
Migration or upgrade issues happen occasionally with some niche setups or when skipping major versions during archiving.
Always backup your archive before upgrading, but know that migrations are deterministic and atomic using Django’s migration system, so a failed migration does not mean your archive is unrecoverable, you just have to downgrade to the previous stable major version then continue upgrading.
archivebox init # this usually applies any necesary migrations (atomically and indempotently, safe to run multiple times)
Repairing a corrupted SQLite3 database file
A corrupted database file can theoretically only happen if an external process or filesystem error corrupts the SQLite3 database (there has only been one report of a user encountering this in real life). If you ever need to repair a corrupted ArchiveBox index you can run the following steps.
Note this is specific to this error, these steps do not apply to other migrations/db errors (see below for other issues):
sqlite3.DatabaseError: database disk image is malformed
Generally all index issues should be fixable by running
You can see the status of Snapshots and find any invalid/orphan/missing snapshots with
[i] [2022-03-24 20:37:27] ArchiveBox v0.6.2: archivebox init > /data [^] Verifying and updating existing ArchiveBox collection to v0.6.2... ---------------------------------------------------------------------- [*] Verifying archive folder structure... + ./archive, ./sources, ./logs... + ./ArchiveBox.conf... [*] Verifying main SQL index and running any migrations needed... Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/django/db/backends/utils.py", line 82, in _execute return self.cursor.execute(sql) File "/usr/local/lib/python3.9/site-packages/django/db/backends/sqlite3/base.py", line 411, in execute return Database.Cursor.execute(self, query) sqlite3.DatabaseError: database disk image is malformed
Steps to fix:
cd ~/archivebox echo '.dump' | sqlite3 index.sqlite3 | sqlite3 repaired_index.sqlite3 mv index.sqlite3 corrupt_index.sqlite3 mv repaired_index.sqlite3 index.sqlite3