Satish Eerpini wrote:
well Fajar, i didnt quite understand your point, how is storage related to the roll back functionality , ... ? can u explain a bit , or refer some resources from where i can understand this ?
In short : (most probably) it will be unrealistic to implement rollback using yum.
A more feasible option would be to implement some sort of backup-restore functionality to achieve that. Rollback would essentially be a restore from a backup from a particular point-in-time.
One way to do so is by utilizing storage-level snapshot/versioning ability, if it has one. This way the backup/restore process will be MUCH faster compared to (for example) normal tar/rsync-based backups.
Regards, Fajar
Thanks SatishOn 4/1/08, *Fajar A. Nugraha* <fajar@xxxxxxxxx <mailto:fajar@xxxxxxxxx>> wrote:Satish Eerpini wrote: > hi Fajar > yes , i actually didn't know that , but what if we make use of the > system file database I'm not sure what you mean by "system file database". > to trace back all the file changes that happened > after the rollback date and then trace back these files to RPM > packages using the databases in the repositiories, ...that would be > fast and a more correct way of doing it ?? > what say ? > > An easier method would be to use some kind of versioning on storage level. For example : - Using Linux on top of LVM with LVM snapshot feature (I haven't test it much) - Using Linux on top of SAN storage with flash-copy/snapshot capability - Using Linux on top of iscsi-exported zfs emulated volume - Using Linux (kernel 2.4) on top of solaris brandZ zone, running on zfs That way the storage will handle snapshot and rollback, not yum. Regards, Fajar
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxxxxx https://lists.dulug.duke.edu/mailman/listinfo/yum
