There is no 'basic' update. When you update with apt-get update/upgrade you will have a 1.4 installation - but with wrong kernel. That is why you need to do a 'dist-upgrade' (do get the new kernel too).
If the vzdump update relies on the new kernel being in place it should have been keept back as dist-upgrade imo, but i guess it doesn't?
A change of the default filename for a backuptool is a rather
critical change, as a lot people may have scripts looking for a particular filename to do something with the backup - like moving it to a remote location.
Apt-get update is commonly used to keep systems uptodate with security fixes and other minor (mostly backward compatible) changes, i doubt the majority of people out there goes and reads changelogs for every single packet introduced with such an update.. so changing something critical like the filename of backups for an backuptool in a non-backward compatible way is very likely to break existing backup routines,
maybe even without people noticing, so the concern of the original poster seems pretty valid to me.
A much better way to introduce this filename change would have been to do either:
- provide a warning to the user (via apt-get while updating) that the backup filename has changed and that he may need to check compatibility if he uses custom scripts to store his backups.
- (a better solution) keep vzdump backward compatible but provide a way to modify the filename on the command line and provide a field in the configuration interface too. (basically im seconding the request frank.pawlik made here).
Here an example how a better solution could look like:
A command line option parsing a formatstring decoding %codes and a text field for this in the web interface.
--filename "formatstring"
%codes in the string could be like in 'date':
%E - VEID (i.e. 101)
%t - container type
%n - clusternode name
%y - last two digits of year (00..99)
%Y - year
%m - month (01..12)
%d - day of month (e.g, 01)
%H - hour (00..23)
%M - minute (00..59)
%S - second (00..60)
%s - seconds since 1970-01-01 00:00:00 UTC
[..]
with the
default beeing (to be backward compatible):
"vzdump-%e" (creating vzdump-101.tar like files)
and your new format would then be avaiable by using:
"vzdump-%t-%e-%Y_%m_%d-%H_%M_%S" (creating vzdump-openvz-105-2009_10_09-11_04_43.tar like files)
and this would also offer countless other possebilities how to name backup files, like it could also include the proxmod nodename to have multiple proxmox servers share the same backup space
Why would anyone want to keep the old format?
And before you ask... while your new --maxfiles option is neat it only helps with local backup files or network shares.. it doesn't really help managing the amount of files if your storing them remotely at a later time, like lets say you move them to some remote ftp location with a simple cronjob script in the following night and assume the old backups get overwritten in the process.
Sadly i lack the time atm to implement my proposal of a better solution up there myself, so if i couldn't convince you to go for it, consider at least adding a warning for the update process so people don't get surprised if their custom backup scripts fail due to the filename change.
BTW thanks for the --script option tho, thats pretty awesome.. i guess a real cheap way of restoring the old filename could be to just hook "backup-end" and rename the file afterwards.
