In cases where I've been concerned about the migration of data (e.g. copying my entire home directory from one system to another), I've used fingerprint to generate a transcript on the source machine, and then run it on the destination machine, to reassure me that the data was copied correctly and completely.

rotate

prune

Preserving web content never really left my mind ever since taking screenshots of old sites and putting them in my personal museum. The Internet Archive’s Wayback Machine is a wonderful tool that currently stores 748 billion webpage snapshots over time, including dozens of my own webdesign attempts, dating back to 2001. But that data is not in our hands. Should it? It should. Ruben says: archive it if you care about it: The only way to be sure you can read, listen to, or watch stuff you care about is to archive it. Read a tutorial about yt-dlp for videos. Download webcomics. Archive podcast episodes.

»Bei Feuer sind die schwarzeingebundnen Exzerpten zuerst zu retten«, wies der Dichter Jean Paul seine Frau vor Antritt einer Reise im Jahr 1812 an.

I can't reverse it, but maybe somebody who understands how Chrome does the decryption can. The ability is there, its not that Chrome can't decrypt them, it is that Chrome won't decrypt them due to false "security".And if Chrome actually, genuinely can no longer decrypt passwords after they have been restored from backup, then that is a shockingly bad bug in their password manager.

take advantage of LVM snapshots. Take snapshots before and after an upgrade. In case, if the system is in unrecoverable position, rollback to the last snapshot from a system rescue LiveCD. A useful program for this, as well as regular system backups is timeshift

Not necessarily. Hosting companies tend to keep your backups in the same place as your primary files. You don’t carry around a copy of your birth certificate along with the actual one – you keep the real one safe at home for emergencies. So why not do the same for your backups? CodeGuard provides safe, offsite backup that is 100% independent from your hosting provider.

involve a combination of Local backup for fast backup and restore, along with Off-site backup for protection against local disasters

Recent backups are retained locally, to speed data recovery operations.

After the initial backup, future backups are differential, both in the files that are transferred and the files that are stored on your behalf.

Of course, just because your users want a copy of their data doesn't necessarily mean that they're abandoning your product. Many users just feel safer having a local copy of their data as a backup.

For any type of full backup, on an active server, it's recommended that you snapshot the filesystem first, then run your backup script on the contents of the snapshot. Your filesystem has to be on LVM to use snapshots, though, and have enough free physical extents (un-partitioned space) to shore up the amount of expected changed data during the snapshot window (more for very busy servers, less for not-so-busy servers). Look here... http://www.tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html

Both /proc and /sys are virtual filesystems which reflect the state of the system, and allow you to change several runtime parameters (and sometimes do more dangerous things, like directly writing to the memory or to a device). You should never backup or restore them.

You might think that a one-line configuration file is not worth backing up. However, if it took you three hours to figure out how to set that configuration, it will probably take you three hours again in six months time.

I am not concerned with any need to exactly restore the system if there is a crash. I have had three previous computers, none of them failed, but I kept manual backups on external hard drives and just use them, now, as a source for any material on them that I still need.

So if you create one backup per night, for example with a cronjob, then this retention policy gives you 512 days of retention. This is useful but this can require to much disk space, that is why we have included a non-linear distribution policy. In short, we keep only the oldest backup in the range 257-512, and also in the range 129-256, and so on. This exponential distribution in time of the backups retains more backups in the short term and less in the long term; it keeps only 10 or 11 backups but spans a retention of 257-512 days.

But just creating the backups will not save your business. You need to make regular backups and keep the most recent copies at a remote location, that is not in the same building or even within a few miles of your business location, if at all possible. This helps to ensure that a large-scale disaster does not destroy all of your backups.

No backup regimen would be complete without testing. You should regularly test recovery of random files or entire directory structures to ensure not only that the backups are working, but that the data in the backups can be recovered for use after a disaster. I have seen too many instances where a backup could not be restored for one reason or another and valuable data was lost because the lack of testing prevented discovery of the problem.