[Ausum Studio]

Use case: Create a new Zope instance. Perform some changes and then pack the database to remove objects revisions older to 0 days. You want a clean instance to start with. Now create a cron job to daily pack the database to remove objects older to 14 days, and start to use your instance. Zope won't pack the database at all, and I guess it will be for the first 2 weeks, because it won't find revisions older to 14 days during that time.

Is that normal behaviour?

I don't know what "normal" means, but it's the behavior you're asking for in that scenario.

Telling by the interface text at the Database Management tab, it looks like the command would create a Data.fs.old file even though there weren't older revisions than the number set, meaning that by default the packing would create an exact copy of the current Data.fs (to keep all changes), at least until there were revisions to remove.

If you're using a current ZODB (anything at or after 3.2.1c1; 3.2.5 is the latest stable release in the 3.2 line), an attempt to pack to a time earlier than the most recent time ever packed to shouldn't do anything more than raise a FileStorageError with this detail: The database has already been packed to a later time or no changes have been made since the last pack

The problem is that if you rely on Data.fs.old for backup purposes,

Sorry, that's not a reasonable backup strategy. The intended way to do FileStorage backup is explained here: http://zope.org/Wikis/ZODB/FileStorageBackup

you'll find that your 13th day Data.fs.old is exactly as that of day one.

Which is one reason for doing backups the intended way <wink>.

An even though you had never packed the database to 0 days, the problem would come up if, for any reason, you feel like it's time to manually pack the database to 0, in between those two weeks.

Manually packing the database to 0 is a novel meaning for "never packed the database to 0 days" <wink>.

Your cron job won't modify the existing Data.fs.old for the following two weeks.

Am I missing something? Thanks in advance,

You're missing that regular backups are needed regardless of packing -- tying backups to packing is poor practice. The intended backup procedure is independent of when pack does or doesn't happen to get rid of something. In fact, it goes faster if packing doesn't occur (so long as that's true, it can do quick incremental backups instead of a full backup -- read the page referenced above).