BitbyBit

BitbyBit backs up other people's databases. Each user signs in, registers connection profiles for the databases they own, and runs backups on demand or on a cron schedule. Backups are compressed, checksummed, and pushed to local disk or a cloud bucket — and verified against that checksum before they are ever restored.

Prerequisites: JDK 21, a MySQL 8 server for the platform's own metadata, and the client binaries for whichever databases you intend to back up (mysqldump, pg_dump, mongodump). No Maven install needed — the wrapper is included.

1. Create the platform database

mysql -u root -p < BitbyBit/docs/schema.sql

2. Supply your secrets

Create BitbyBit/src/main/resources/application-secrets.properties. This file is gitignored and is the only place credentials belong:

spring.datasource.username=your_mysql_user
spring.datasource.password=your_mysql_password

# Exactly 32 characters. See the warning under Security.
app.encryption.key=change_me_to_32_characters_long!

# Optional — only needed for the cloud destinations you actually use
aws.s3.access-key=
aws.s3.secret-key=
azure.blob.connection-string=
gcp.storage.credentials-json-path=

Environment variables work too (SPRING_DATASOURCE_USERNAME, APP_ENCRYPTION_KEY, …). Startup fails with a clear message if neither source supplies them.

3. Point at your client binaries

Edit BitbyBit/src/main/resources/config.properties if your tools aren't in the default install locations. Include the trailing separator:

mysql.bin=C:\\Program Files\\MySQL\\MySQL Server 8.0\\bin\\

4. Run

cd BitbyBit && ./mvnw.cmd spring-boot:run

_{On macOS or Linux use ./mvnw spring-boot:run.}

This starts the interactive terminal UI. To run headless as a server instead — for the REST API once it lands (Phase 4) — start with the web profile, which suppresses the CLI so it doesn't hold stdin:

cd BitbyBit && ./mvnw.cmd spring-boot:run -Dspring-boot.run.profiles=web

BitbyBit is an interactive terminal application. The menus nest in the order you'd actually work:

Sign up / Log in
   └── Pick a database flavor          MySQL · MongoDB · PostgreSQL
         └── Pick a connection profile  (or add one)
               ├── Test Connection
               ├── Backup ─────────────► Local · S3 · Azure · GCS
               ├── Restore ────────────► browse local or cloud backups
               ├── View Backup History
               └── Manage Schedules ───► list · add cron · enable/disable

com.Database.BitbyBit
├── auth/         Sign-up, login, lockout, Bearer-token sessions
├── dto/          Request/response shapes — no controller returns a JPA entity
├── web/          REST controllers (auth, profiles, backups)
├── model/        10 JPA entities
├── repository/   Spring Data JPA interfaces
├── service/      Encryption, connection profiles, the backup orchestrator, scheduling
├── strategy/     Per-engine connect / backup / restore
├── storage/      StorageProvider: local, S3, Azure, GCS
├── scheduler/    Quartz job that runs a scheduled backup
├── config/       Security filter chain, cloud clients, binary paths, executor pool
├── util/         Archive, checksum and validation helpers
└── runner/       The interactive CLI (default run mode; suppressed under --spring.profiles.active=web)

InteractiveCliMenu / BackupQuartzJob / (Phase 4) BackupController
   │  user or scheduler picks profile + destination
   ▼
BackupOrchestrator                          ── the one path all three share
   │
   ├── resolveDestination()                 ── bucket/region defaults per storage type
   ▼
BackupJobService.startBackupJob()          ── row written, status RUNNING
   │
   ▼
DatabaseStrategy (MYSQL | POSTGRESQL | MONGODB)
   │  ProcessBuilder → mysqldump / pg_dump / mongodump
   │  (submitBackup(): runs on a bounded executor — caller gets the job id immediately)
   ▼
BackupArchiveUtils                          ── zip, then SHA-256
   │
   ▼
StorageProvider.uploadFile()                ── skipped for local-only
   │
   ▼
BackupJobService.completeBackupJob()        ── size, checksum, duration, COMPLETED

users (1) ──┬── (N) user_services
            ├── (N) connection_profiles ── (N) backup_jobs ── (N) backup_manifests
            ├── (N) storage_profiles     ── (N) backup_jobs
            ├── (N) scheduled_backups
            ├── (N) user_sessions
            ├── (N) user_audit_log
            └── (N) password_reset_tokens

cd BitbyBit && ./mvnw.cmd test

110 tests total. The integration suites sign up and log in for real, then use the returned Bearer token against protected endpoints — auth isn't mocked. See docs/architecture.md for what each covers, including why one test deliberately skips @Transactional — it's what caught a real LazyInitializationException bug that the other 109 tests structurally could not.

Full detail on Phase 4 — API surface, security checklist, screen-by-screen status — lives in docs/frontend_plan.md, which is kept current as the phase progresses rather than duplicated here.

Designed but not yet built — the tables and entities exist, nothing writes to them:

• backup_manifests → selective, table-level restore
• user_audit_log → immutable action trail
• user_services → per-user feature entitlements
• password_reset_tokens → password recovery

(user_sessions is no longer in this list — Phase 4.1 wired it up for opaque Bearer-token issuance, validation and revocation.)

Also worth building: a retention policy (nothing currently deletes old backups), per-user cloud credentials (the buckets are global today), encryption of the backup archive itself, and failure notifications for unattended scheduled runs.