Error writing file: No space left on device — backup retention after failed save

Short answer

No, nano never deletes a backup file — but it also never accumulates more than one per target file. On every save of an existing file with -B/--backup enabled, nano renames the current file to filename~ and then writes the new contents to the original name. Because the backup name is fixed, the next successful save simply overwrites whatever stale ~ file was left behind by the failed attempt. There is no configuration option in nano to purge backups after a successful write or to cap how many exist; if you need retention limits, that has to come from external tooling.

Why repeated failures don't pile up backups

The worry in the question — that low-disk environments could accumulate orphaned backups — doesn't materialize, because of how the backup-before-write strategy works (introduced in nano 3.0 and still the model in 8.x):

1. Rename file → file~ (this replaces any existing file~).
2. Write the buffer to a new file.

If step 2 fails with No space left on device, your data is still safe: file~ holds the previous contents and the original path is either absent or incomplete. When you free space and save again, step 1 renames the current file over the old backup, so the stale one is replaced rather than joined by a sibling. At any moment there is at most one file~ per file.

What nano does not give you

• No option to remove the backup after a successful write — the ~ file is kept by design as your one-level undo.
• No versioning or rotation (no file~1~, file~2~, etc.), so there is also nothing to cap.
• No hook or exit-status mechanism to trigger cleanup on save.

So "retention" in nano is effectively "keep exactly one backup forever." If that doesn't fit, the standard approach is a periodic sweep:

find /path/to/workdir -name '*~' -type f -mtime +7 -delete

Scope the find to the directories you actually edit, and test with -print before adding -delete — a *~ glob can catch files from other editors too.

One caveat worth checking: --backupdir fallback

If you use --backupdir or $BACKUP_DIR and that directory is unwritable (or, relevant here, on the full filesystem), nano silently falls back to writing the backup in the current directory — documented behavior since 6.0. The single-backup overwrite rule still holds, but the backup may land somewhere you didn't expect, and a later cleanup script pointed only at the backup dir would miss it. After a disk-full incident, it's worth checking both locations:

ls -l file~            # current directory fallback
ls -l "$BACKUP_DIR"/file~ 2>/dev/null

Verifying this yourself

The behavior is easy to confirm on a scratch filesystem (a small tmpfs mount works well):

1. nano -B test.txt, write and save; confirm test.txt~ exists.
2. Fill the filesystem (dd if=/dev/zero of=filler bs=1M), edit, and save; expect the ENOSPC error with the backup still present.
3. Delete the filler, save again, and check that test.txt~ has a fresh timestamp and that exactly one backup exists.

This reflects nano 8.x behavior as documented and observed; the backup-before-write model has been stable since 3.0, but if you're on a different major version, the three-step test above is the authoritative check for your build.