initial commit

libvirt.md

@@ -0,0 +1,13 @@
+---
+author: Alvie Rahman
+date: \today
+title: libvirt notes
+---
+
+# issues
+
+## default network is not running
+
+```bash
+# virsh net-start default
+```

linux.md

@@ -0,0 +1,19 @@
+---
+author: Alvie Rahman
+date: \today
+title: linux notes
+---
+
+# user stuff
+
+## add user to group
+
+```bash
+# usermod -a -G group user
+```
+
+## change primary user group
+
+```bash
+# usermod -g group user
+```

postgres.md

@@ -0,0 +1,134 @@
+---
+author: Alvie Rahman
+date: \today
+title: postgres notes
+---
+
+\tableofcontents
+
+# Chapter 24: Backup and Restore[^c24]
+
+Three types of backups:
+
+- SQL dump---create text file of SQL commands that can recreate the database
+
+   `pg_dump dbname > outfile`
+
+   To restore: `psql dbname < infile`
+
+   - must be run as database superuser
+   - can be run remotely
+   - set host and username with `-h` and `-U` switches
+
+- File system level backup
+
+   `tar -cf backup.tar /usr/local/pgsql/data`
+
+   - The database server **must** be shut down
+   - You can only backup and restore entire database clusters
+
+- Continuous archiving (write ahead log archiving)
+
+   - "We do not need a perfectly consistent file system backup as the starting point."
+   - method can be used to create a continuous backup
+   - supports point in time recovery
+   - can be used to create a warm standby system
+
+   - can only be used to restore an entire database cluster
+   - requires a lot of archival storage
+
+## SQL Dump
+
+### Restoring a dump
+
+Important note before you restore a database:
+
+> Before restoring an SQL dump, all the users who own objects or were granted permissions on objects
+  in the dumped database must already exist. If they do not, the restore will fail to recreate the
+  objects with the original ownership and/or permissions. (Sometimes this is what you want, but
+  usually it is not.)
+
+You should probably read the whole document [here](https://www.postgresql.org/docs/9.1/backup-dump.html)
+
+## File system backup
+
+You can run a FS level backup with minimal downtime with `rsync`:
+
+1. Perform a backup with `rsync` while system is live
+2. Shut down database server
+3. Rerun `rsync` backup command
+4. Restart database server
+
+The second `rsync` command will run significantly quicker as it only has to transfer what has
+changed since the first backup.
+
+## Write Ahead Log (WAL) archiving
+
+- WAL segment files usually get "recycled" by being renamed
+- to archive WAL data, the content of each segment is captured and saved before it is reused
+
+   - you can save the data any way you like
+
+- to enable WAL archiving:
+
+   1. set `wal_level` to `archive` (or `hot_standby`)
+   1. set `archive_mode` to `on`
+   1. set `archive_command` to the command to use to backup
+
+      - e.g.
+
+         ```
+         archive_command = 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'  # Unix
+         archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows
+         ```
+
+         where `%f` is the filename of the file to archive and `%p` is the path of file to archive:
+
+         ```
+         test ! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065
+         ```
+
+      - The command must only ever return a exit status of 0 **only if it succeeds*
+
+         - postgres will recycle the file if the command returns 0
+
+      - The archived data should have minimal access permissions
+      - the archive command should generally refuse to overwrite files and return non-zero
+      - In writing your archive command, you should assume that the file names to be archived can be
+        up to 64 characters long and can contain any combination of ASCII letters, digits, and dots.
+      - It is not necessary to preserve the original relative path (`%p`) but it is necessary to
+        preserve the file name (`%f`).
+   
+   1. make a base backup
+
+### make a base backup
+
+1. ensure WAL archiving is enabled and working
+2. issue the following command as superuser:
+
+   ```
+   SELECT pg_start_backup('label');
+   ```
+
+   - `label` is any string to uniquely identify backup operation, e.g. the full path where you
+      intend to put the backup dump file
+   - It does not matter which database within the cluster you connect to to issue this command
+3. Perform the backup, using any convenient file-system-backup tool such as tar or cpio
+   (not pg_dump or pg_dumpall). It is neither necessary nor desirable to stop normal operation of
+   the database while you do this.
+4. issue the following command as superuser:
+
+   ```
+   SELECT pg_stop_backup();
+   ```
+
+   this terminates the backup mode and performs an automatic switch to the next WAL segment
+
+
+> You can also use the pg_basebackup tool to take the backup, instead of manually copying the files.
+  This tool will do the equivalent of pg_start_backup(), copy and pg_stop_backup() steps
+  automatically, and transfers the backup over a regular PostgreSQL connection using the replication
+  protocol, instead of requiring file system level access. pg_basebackup does not interfere with
+  file system level backups taken using pg_start_backup()/pg_stop_backup().
+
+[^c24]: https://www.postgresql.org/docs/9.1/backup-dump.html