# bilibili-backup: moving your own Bilibili account data across

> bilibili-backup is a Java desktop application that backs up and restores a Bilibili account's own data, including follows, favourites, watch later, history and collections, so an account can be migrated or reset. The project is unmaintained and its functionality has moved to a separate toolkit.

**hzhilong/bilibili-backup** — 一键对B站账号进行数据备份和还原，方便账号数据迁移/快速转生(哔哩哔哩 bilibili)。One-click backup and restore of B station account data, convenient account data migration/quick reincarnation.

- Repository: https://github.com/hzhilong/bilibili-backup
- Stars: 583 · Forks: 15
- Language: Java
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/hzhilong-bilibili-backup

## What the tool does, and the warning above it

The application provides one-click backup and restore of a Bilibili account's data, which the description frames as convenient for account data migration or a quick reset of an account. The README opens with a warning that the project has stopped maintenance, that the related functionality has all been migrated to a separate project, the toolkit linked from the notice, and the features are organised under backup, restore and clear for follows and follow groups, the blacklist, the anime and drama subscriptions, the favourites, the saved columns, the saved video collections, watch later, viewing history and the follower list, with the followers explicitly noted as not supporting restore. There is also a section for looking up accounts that have been cancelled, which can return the follow and follower counts and the videos uploaded, and back up data including the favourites, the saved video collections and the subscriptions. The top level of the repository is a Maven project with a `pom.xml` and a `src/` directory, and the primary language is Java.

## Why an account would be reset at all

The README lists the reasons a user might want a fresh account, and it is worth reading because it shows what a platform considers sticky about a user identity. Being blocked by a particular content creator and therefore losing access to that creator's posts and live streams is the first. Then the question of whether resetting the live room spending record and the spending level is possible. Then comments that keep getting deleted, and whether the related system can be reset. Then statements posted on the old account. Then accounts where some functions are restricted. Then the case of selling a game account, where the data has to be migrated and the original account cleared afterwards. The list ends with an invitation to add more. The pattern is that the value of a fresh account is a clean slate for anything the platform attaches to the identity, and a backup tool exists to carry across the parts that are worth keeping.

## The rest of the toolbox is more than backup and restore

Beyond the migration core, the feature list carries a set of smaller utilities that reveal the shape of the platform's data model. There is marking all private messages as read or deleting them, deleting all system messages, forcibly enabling the automatic reply function for private messages, backing up video danmaku with the ability to trace back the sender, quickly copying someone else's public favourites, and favouriting all of another user's uploads. There is also an experimental feature for answering the questions in the account's own registration quiz. The danmaku backup and the reverse lookup of the sender is the most interesting of these, because it turns a comment stream into a structured record rather than a list of links. The tool also supports querying accounts that have been cancelled, which is a niche capability that only makes sense because the platform keeps some state for them.

## Segmented processing exists because the platform rate limits you

The most practically useful piece of engineering in the README is the note that some backup and restore items support segmented processing for the case where there is too much data. The examples given for why a user would want a reset involve having thousands of follows. That is a scale problem, and a scale problem against a server with rate limiting is a different problem from a scale problem against a local disk. The notes section spells out the consequences. A new account should be raised to level two first, and a freshly registered account is suggested to be used for a couple of days on its own before a large operation. Too much data invites risk control, particularly when restoring follows, and the recommendation is to tick the segmented processing option. These are the details that separate a tool that works once from a tool that works on a real account with a real history.

## The failure modes the options exist to handle

Several of the settings in the README are named after the specific failure they avoid, which tells you what actually goes wrong. There is an option to ignore the new account's existing data when restoring and restore directly instead, for the case where the target account already has too much data. There is an option to continue restoring the next item when one restore fails, and the reason given is that some creators cannot be followed, so a failure during restore would otherwise stop the whole backup. And there is an option to manually select the favourites folders to operate on, for when there are too many of them. The pattern is that the tool is designed to be run against a live service where individual operations can fail for reasons outside the user's control, and the default behaviour would otherwise be to stop on the first error.

## The platform support, the build and the download options

The supported platform is Windows, and the README notes that on macOS and Linux you can download the source and compile it yourself, with a link to a packaging project for that. The application is written in Java, and the acknowledgements section credits two projects, a collected API documentation repository for the service and a Look and Feel library, which points to a Swing based user interface. Downloads are offered from the GitHub releases page and from a file hosting mirror with a password given in the README. The repository itself is small, with a `.gitignore`, the `LICENSE`, an `assets/` directory holding the icon and the interface screenshots, the Maven `pom.xml`, a `readme.md` and the `src/` directory. The project is MIT licensed, and there is a pointer to a separate project for backing up the data of Windows applications.

## Where this is the wrong choice

The limits are mostly about the situation rather than the code. First, and decisively, the project is over. The maintenance notice points to a successor, the last push was on 2026-06-30 and the most recent release is v2.1.6 from 2026-04-03, with the two before it from 2025. Starting from this code today means starting from a fork of a retired tool. Second, the tool needs an account in good standing, since the notes say to raise a new account to level two, to use a fresh account for a couple of days first, and to expect risk control when restoring large amounts of data, which means a large account migration is a project with a real chance of being rate limited halfway through. Third, it is Windows first, and the macOS and Linux route is a source build rather than a supported package, which is a friction the README is candid about. Fourth, the tool is a set of API calls against a service that can change its behaviour, and a service that changes its authentication or its endpoints breaks the tool silently, since there is no compatibility contract. And fifth, restoring a backup onto an account is exactly the operation where a mistake damages data, which is why the segmented and continue-on-failure options exist and why you should test on a throwaway account first.

## Conclusion

bilibili-backup is worth reading if you want to understand what a self-service account migration for a consumer service actually involves, because the feature list is a good map of the account state a modern platform keeps and of the pain of moving it. It is the wrong tool to adopt today, because the README states plainly that the project has stopped maintenance and that the functionality has moved elsewhere, and the last push was on 2026-06-30 with the last release v2.1.6 from 2026-04-03. If you want to use it, follow the pointer to the successor project rather than starting from this code, and if you are evaluating the design, read the notes about segmented processing and rate limiting before you run anything at scale. The licence is MIT.

## FAQ

### Is bilibili-backup still maintained?

No. The README opens with a warning that the project has stopped maintenance and that the related functionality has all been migrated to a separate toolkit project. The last push was on 2026-06-30 and the most recent release is v2.1.6 from 2026-04-03.

### What data can bilibili-backup back up and restore?

Follows and follow groups, the blacklist, anime and drama subscriptions, favourites, saved columns, saved video collections, watch later, viewing history and the follower list, with the followers noted as not supporting restore. It can also clear data, look up cancelled accounts and back up video danmaku with sender lookup.

### Which platforms does bilibili-backup support?

Windows is the supported platform. On macOS and Linux you can download the source and compile it yourself, using a separate packaging project referenced in the README.

## Sources

- [hzhilong/bilibili-backup on GitHub](https://github.com/hzhilong/bilibili-backup)
- [Issues](https://github.com/hzhilong/bilibili-backup/issues)
- [License: MIT](https://github.com/hzhilong/bilibili-backup/blob/main/LICENSE)
- [README](https://github.com/hzhilong/bilibili-backup/blob/main/README.md)
- [Releases](https://github.com/hzhilong/bilibili-backup/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hzhilong-bilibili-backup