If you have recently upgraded your Drupal site or updated your local development environment, you might have encountered a frustrating surprise. You type drush archive-dump (or the shortcut drush ard) to create a quick backup, only to be met with a blunt error message:

The Drush command 'archive-dump' could not be found.

You check your drush core-status, and everything looks perfect. Drupal is bootstrapped, the database is connected, and other commands work fine. So, where did one of the most popular Drush commands go? In this guide, we will explore why archive-dump was removed from Drush 9 and later versions, and more importantly, how you should be backing up and migrating your Drupal sites in the modern era.

The Evolution of Drush and the Composer Revolution

To understand why archive-dump disappeared, we have to look at how Drupal development has changed. In the days of Drupal 7 and early Drupal 8, many developers managed their sites by manually downloading modules or using drush dl. The archive-dump command was designed for this world; it would package your entire web root, your database, and your Drush configuration into a single .tar.gz file.

However, with the release of Drush 9, the tool underwent a massive architectural shift to align with Composer-based workflows. In a modern Drupal project, your code isn't just a collection of files in a folder; it is a managed dependency tree.

Community discussions and official Git commits reveal that archive-dump was intentionally removed because it didn't fit the modern paradigm. Archiving the vendor directory, for example, is considered bad practice because those dependencies should be managed via composer.json. Furthermore, the logic required to safely port a site archive across different environments was becoming increasingly fragile as Drupal's directory structures became more complex.

How to Back Up Drupal 9, 10, and 11 Without archive-dump

Since archive-dump is no longer available, you need to adopt a modular approach to backups. Instead of one command that does everything poorly, you should use specific tools that do each part of the job perfectly. A complete Drupal backup consists of three main components: the database, the uploaded files, and the configuration.

1. Backing Up the Database

The most critical part of your site is the data. You can still use Drush to export your database efficiently using the sql-dump command.

drush sql:dump --result-file=../backups/backup-$(date +%F).sql

This command creates a standard SQL file. By saving it one directory above your web root (../), you ensure that the backup isn't publicly accessible via a browser if you accidentally leave it there.

2. Exporting Configuration

In modern Drupal, your settings, content types, and view definitions are stored in the database but should be managed as code. Before backing up, always export your configuration:

drush config:export -y

This will sync your active configuration to your config/sync directory (as defined in settings.php). These YAML files should be committed to your Git repository, making them a permanent part of your "code backup."

3. Archiving the Files Directory

The archive-dump command used to grab your sites/default/files folder. Now, you should handle this using standard Linux tools like tar or rsync. This gives you much more control over exclusions (like image styles or temporary files).

tar -czf ../backups/files-backup.tar.gz web/sites/default/files

Best Practices for Site Migrations

If you were using archive-dump to move a site from a local environment to a live server, the modern workflow is slightly different but much more robust.

  1. Git for Code: Push your code (including composer.json, composer.lock, and your exported configuration) to a private repository (GitHub, GitLab, Bitbucket).
  2. Composer on Server: On the destination server, run composer install --no-dev. This ensures all dependencies are exactly the same as your local environment without bloating the server with development tools.
  3. Database Import: Transfer your SQL dump to the server and use Drush to import it: bash drush sql:query --file=backup.sql
  4. Config Import: Finally, ensure the configuration is synchronized: bash drush config:import -y

Common Mistakes to Avoid

When transitioning away from the old archive-dump workflow, developers often fall into a few common traps:

  • Including the Vendor Directory: Do not include the vendor folder in your manual backups or Git repo. It is much safer to let Composer rebuild it. This prevents issues with platform-specific binaries (like those used in some PHP libraries).
  • Forgetting the .env File: If you use a .env file to manage secrets and database credentials, remember that this file is usually excluded from Git. You must back this up manually or store the values in a secure password manager.
  • Ignoring the Private Files Directory: If your site uses a private file system for sensitive documents, ensure your backup scripts include that path, which is often located outside the web or public_html root.

Frequently Asked Questions

Is there a replacement module for archive-dump?

While there isn't a direct 1:1 Drush replacement, the Backup and Migrate module remains a popular choice for site administrators who prefer a UI-based approach. It allows you to schedule database and file backups directly from the Drupal admin interface.

Can I still use Drush 8 to get archive-dump back?

You can technically use Drush 8 for older Drupal 7 sites, but Drush 8 is not fully compatible with the architecture of Drupal 9, 10, or 11. Attempting to use an old version of Drush on a new version of Drupal will lead to dependency conflicts and potential data corruption.

Why can't I find the 'ard' alias anymore?

The ard alias was tied specifically to the archive-dump command. When the command was removed from the Drush core source code in version 9.x, all associated aliases were also removed.

Wrapping Up

The loss of archive-dump might feel like a step backward in terms of convenience, but it represents a significant step forward in terms of professional DevOps standards. By separating your database, your files, and your code dependencies, you create a more reliable and scalable deployment process.

To keep your workflow efficient, consider writing a simple Bash script that combines drush sql:dump and tar into a single command. This gives you the convenience of the old archive-dump with the precision and compatibility of modern Drupal development.